Re: default_transaction_isolation = serializable causes crash under Hot Standby

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <simon(at)2ndQuadrant(dot)com>
Cc: <robertmhaas(at)gmail(dot)com>,<pgsql-hackers(at)postgresql(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: default_transaction_isolation = serializable causes crash under Hot Standby
Date: 2012-04-29 12:40:58
Message-ID: 4F9CF08A020000250004752B@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> Kevin Grittner wrote:
>
>> But if you set it in the postgresql.conf file, it's not pretty:
>>
>> kevin(at)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2012-04-29 14:27:29 Re: Re: xReader, double-effort (was: Temporary tables under hot standby)
Previous Message Simon Riggs 2012-04-29 12:23:10 Re: 9.2 release notes, beta time?