On Fri, 2009-01-23 at 18:22 +0200, Heikki Linnakangas wrote:
> > @@ -1601,6 +1602,24 @@ BufferProcessRecoveryConflictsIfAny(volatile
> > BufferDesc *bufHdr)
> > {
> > XLogRecPtr bufLSN = BufferGetLSN(bufHdr);
> >
> > + /*
> > + * If the buffer is recent we may need to cancel ourselves
> > + * rather than risk returning a wrong answer. This test is
> > + * too conservative, but it is correct.
> > + *
> >>> + * We only need to cancel the current subtransaction.
> > + * Once we've handled the error then other subtransactions
> > can
> > + * continue processing. Note that we do *not* reset the
> > + * BufferRecoveryConflictLSN at subcommit/abort, but we do
> > + * reset it if we release our last remaining sbapshot.
> > + * see SnapshotResetXmin()
> > + *
>
> Is it really enough to cancel just the current subtransaction? What if
> it's a serializable transaction?
I did originally think that when I first looked at the problem. I'm
sorry if I say that a lot.
If you have a serializable transaction with subtransactions that suffers
a serializability error it only cancels the current subtransaction. That
means it's snapshot is still valid and can be used again. By analogy, as
long as a transaction does not see any data that is inconsistent with
its snapshot it seems OK for it to continue. So I think it is correct.
(Bizarrely, this might mean that if we did this programatically in a
loop we might keep the system busy for some time while it continually
re-reads data and fails. But that's another story).
You remind me that we can now do what Kevin has requested and throw a
errcode(ERRCODE_T_R_SERIALIZATION_FAILURE) at this point, which I agree
is the most easily understood way of describing this error.
(I was sorely tempted to make it "snapshot too old", as a joke).
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
