From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: default_transaction_isolation = serializable causes crash under Hot Standby |
Date: | 2012-04-27 14:21:06 |
Message-ID: | 4F9A6502020000250004745D@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> When I do this:
>
> rhaas=# set default_transaction_isolation = 'serializable';
> SET
> rhaas=# begin;
> BEGIN
> rhaas=# select 1;
>
> Then I get this:
>
> TRAP: FailedAssertion("!(!RecoveryInProgress())", File:
> "predicate.c", Line: 1637)
> LOG: server process (PID 290) was terminated by signal 6: Abort
> trap
>
> The root of the problem here seems to be that we're imagining that
> it's possible to prevent serializable mode from being used under
> HS from within the check function for the transaction_isolation
> GUC - see check_XactIsoLevel. However, because there's a second
> GUC (default_transaction_isolation) that can also be used to
> change the initial setting, it doesn't work.
>
> I'm not exactly sure what the best way to fix this is. I assume
> that this problem also exists in 9.1, but I haven't checked.
My first thought was that if we can detect that we are in HS, we
should probably throw an ERROR on an attempt to set
default_transaction_isolation = 'serializable'. But that raises the
question about what to do with environments where people want the
master to be running with that default (set from postgresql.conf) --
fail-over could be, well, "interesting". We haven't run into this
situation yet because we don't use our production postgresql.conf on
our hot standbys -- when we make a base backup we rename
postgresql.conf to postgresql.conf.production and copy in a special
configuration file. For those who want the same configuration on
both, and who want to use serializable transactions on the master, I
don't see a really clean solution. Does anyone else?
We didn't want to allow SERIALIZABLE to be set while still allowing
read-only anomalies like this (assuming T3 was on the HS):
http://wiki.postgresql.org/wiki/SSI#Deposit_Report
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-04-27 14:35:01 | Re: Request to add options to tools/git_changelog |
Previous Message | Andrew Dunstan | 2012-04-27 13:25:47 | Re: A problem with dump/restore of views containing whole row references |