Simon Riggs wrote: > Kevin Grittner wrote: > >> But if you set it in the postgresql.conf file, it's not pretty: >> >> kevin@kevin-desktop:~$ psql -p 5433 test >> psql: FATAL: can not create a serializable snapshot during >> recovery >> >> Ideas? > > The patch as submitted doesn't do anything useful for the case > where the setting in .conf is serializable. Precisely the point I was trying to make. We discussed an approach, I tried it, but that approach doesn't work. So we need new ideas. > IMHO the desired behaviour would be > > * 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'm not sure how well that plays for all users of HS. It would work for us because there are a number of settings we want to change on a HS; we use a different postgresql.conf from the master, so this works fine. I am concerned about people who want to promote the HS to a new master without swapping in a different conf file and doing a reload or restart -- if they want serializable transactions as the default on their master, how would this work? > * throw a WARNING if serializable is stated in other cases, and > downgrade the request to repeatable read Yeah, that idea has been in the back of my mind all along, but I couldn't find a comfortable way to reconcile that with the point above and with the fact that we all seem to hope to some day have a way to run true serializable transactions under HS. > Throwing a WARNING is better than an ERROR, since it reduces the > level of application editing to make it work for HS. Or better > still, just document that serializable currently means repeatable > read when executed on an HS. Somehow it just "feels" wrong, but if nobody can propose a less painful alternative, perhaps that is best. For now. > On another note, what happened to the plan to export regular > serializable snapshots to the standby for use as deferred > snapshots? For the record, I think the most promising variation on that was to include a new WAL record type or a bit in the WAL record header to flag points in the WAL stream at which a transaction on HS could not see any anomalies. A serializable transaction on a HS would use a snapshot built at that point, either by waiting for one or having the WAL receiver keep the latest known safe one available. That is still on my list of things I would like to do, but round tuits are hard to come by these days, and there are a number of items higher on that list. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
