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
