Re: default_transaction_isolation = serializable causes crash under Hot Standby
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Date: 2012-04-29T19:43:19Z
Lists: pgsql-hackers
On Sun, Apr 29, 2012 at 8:20 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > * prevent default_transaction_isolation = serializable as a default > setting when we enter Hot Standby by throwing a FATAL error from the > startup process. I can help implement that if we agree. I am strongly disinclined to go that route, because (1) our customers, at least, really hate it when the standby won't start up, and I think we should be very careful about finding more reasons for that to happen; and (2) it's not bullet-proof anyway, because there is still ALTER USER .. SET and ALTER DATABASE .. SET and maybe a few other methods as well. Keep in mind, also, that this has to be back-patched to 9.1; so if we go this route then someone might shut down their server, upgrade the binaries, restart the server, and have it fail to start. I think that's not a nice thing to do in a minor release. > * throw a WARNING if serializable is stated in other cases, and > downgrade the request to repeatable read I think this would be reasonable, but it's still my second choice. The advantage of throwing an ERROR is that someone will presumably be forced to realize that a problem exists and fix it, whereas a WARNING may just generate a combination of log spam and unexpected behavior forever. Also, we currently block cases where you try to set transaction_isolation by throwing an ERROR, so it seems a bit more consistent to do that in other cases as well. Still, it's a reasonable choice, and certainly better than failing an assertion. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company