Robert Haas <robertmh...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
