diff options
author | Harry Marr <harry.marr@gmail.com> | 2015-10-28 16:30:02 +0000 |
---|---|---|
committer | Harry Marr <harry.marr@gmail.com> | 2015-10-28 18:45:54 +0000 |
commit | a456acb2f2af8365eb9151c7cd2d5a10c189d191 (patch) | |
tree | c7a196f38077b93f73d76e90adb6ced9dd9e55e2 /railties/test | |
parent | 8b7128a142177b3c0f36ec6dd1883bd874b63e78 (diff) | |
download | rails-a456acb2f2af8365eb9151c7cd2d5a10c189d191.tar.gz rails-a456acb2f2af8365eb9151c7cd2d5a10c189d191.tar.bz2 rails-a456acb2f2af8365eb9151c7cd2d5a10c189d191.zip |
Avoid disabling postgres errors
The standard_conforming_strings setting doesn't exist on all versions of
Postgres, but if it does exist, Rails turns it on. Previously this was done by
effectively disabling errors on the Postgres connection, issuing a SET to turn
the setting on, then re-enabling errors on the connection. However, if you're
running pgbouncer in transaction-pooling mode, you can't guarantee that
successive calls to `#execute` will be sent to the same pgbouncer-postgres
connection, so you can end up disabling errors on a different postgres
connection, and never re-enabling them. Future queries on that connection that
result in errors (e.g. violating unique constraints) will leave the connection
in a bad state where successive queries will fail.
This commit sets standard_conforming_strings by issuing an UPDATE to
pg_settings, which will update the setting if it exists, and do nothing if it
doesn't (rather than erroring out like SET would), which means we can remove
the error-disabling code.
It's also worth noting that Postgres has allowed standard_conforming_strings to
be updated since 8.2 (which is the oldest version Rails supports), so
technically we probably don't even need to be defensive here.
Diffstat (limited to 'railties/test')
0 files changed, 0 insertions, 0 deletions