1. 18 11月, 2017 1 次提交
    • M
      Improve AR connection fork safety · f32cff55
      Matthew Draper 提交于
      Use whatever adapter-provided means we have available to ensure forked
      children don't send quit/shutdown/goodbye messages to the server on
      connections that belonged to their parent.
      f32cff55
  2. 13 11月, 2017 1 次提交
  3. 11 11月, 2017 1 次提交
  4. 25 10月, 2017 1 次提交
  5. 21 10月, 2017 1 次提交
  6. 15 10月, 2017 1 次提交
    • R
      Fix longer sequence name detection for serial columns (#28339) · 8877492d
      Ryuta Kamizono 提交于
      We already found the longer sequence name, but we could not consider
      whether it was the sequence name created by serial type due to missed a
      max identifier length limitation. I've addressed the sequence name
      consideration to respect the max identifier length.
      
      Fixes #28332.
      8877492d
  7. 04 10月, 2017 1 次提交
  8. 22 8月, 2017 2 次提交
  9. 21 8月, 2017 1 次提交
  10. 20 8月, 2017 2 次提交
  11. 30 7月, 2017 1 次提交
  12. 20 7月, 2017 2 次提交
  13. 14 7月, 2017 1 次提交
    • C
      Catch postgres connection errors when trying to dealloc the statement pool · 325b3cd6
      Chris Williams 提交于
      connection_active? will sometimes return true when the connection is actually dead/disconnected (see #3392 for a discussion of why this is).  When this happens, a query is run on the dead connection which causes various postgres connection errors to be raised.  This fix catches any such errors and ignores them.
      
      Closes #29760
      325b3cd6
  14. 02 7月, 2017 1 次提交
  15. 01 7月, 2017 2 次提交
  16. 30 6月, 2017 1 次提交
    • R
      Don't cache queries for schema statements · 21d040f9
      Ryuta Kamizono 提交于
      `test_middleware_caches` is sometimes failed since #29454.
      The failure is due to schema statements are affected by query caching.
      Bypassing query caching for schema statements to avoid the issue.
      21d040f9
  17. 29 6月, 2017 1 次提交
  18. 30 5月, 2017 1 次提交
  19. 01 5月, 2017 1 次提交
  20. 27 4月, 2017 1 次提交
  21. 26 4月, 2017 1 次提交
  22. 11 4月, 2017 1 次提交
    • M
      Add comprehensive locking around DB transactions · e4c197c7
      Matthew Draper 提交于
      Transactional-fixture using tests with racing threads and inter-thread
      synchronisation inside transaction blocks will now deadlock... but
      without this, they would just crash.
      
      In 5.0, the threads didn't share a connection at all, so it would've
      worked... but with the main thread inside the fixture transaction, they
      wouldn't've been able to see each other.
      
      So: as far as I can tell, the set of operations this "breaks" never had
      a compelling use case. Meanwhile, it provides an increased level of
      coherency to the operational feel of transactional fixtures.
      
      If this does cause anyone problems, they're probably best off disabling
      transactional fixtures on the affected tests, and managing transactions
      themselves.
      e4c197c7
  23. 26 3月, 2017 2 次提交
  24. 23 3月, 2017 1 次提交
  25. 22 3月, 2017 1 次提交
  26. 14 3月, 2017 1 次提交
  27. 10 3月, 2017 1 次提交
  28. 27 2月, 2017 2 次提交
  29. 26 2月, 2017 1 次提交
  30. 21 2月, 2017 1 次提交
    • E
      Ensure test threads share a DB connection · d6466beb
      eileencodes 提交于
      This ensures multiple threads inside a transactional test to see consistent
      database state.
      
      When a system test starts Puma spins up one thread and Capybara spins up
      another thread. Because of this when tests are run the database cannot
      see what was inserted into the database on teardown. This is because
      there are two threads using two different connections.
      
      This change uses the statement cache to lock the threads to using a
      single connection ID instead of each not being able to see each other.
      This code only runs in the fixture setup and teardown so it does not
      affect real production databases.
      
      When a transaction is opened we set `lock_thread` to `Thread.current` so
      we can keep track of which connection the thread is using. When we
      rollback the transaction we unlock the thread and then there will be no
      left-over data in the database because the transaction will roll back
      the correct connections.
      
      [ Eileen M. Uchitelle, Matthew Draper ]
      d6466beb
  31. 20 2月, 2017 1 次提交
  32. 14 2月, 2017 1 次提交
  33. 13 2月, 2017 2 次提交