Re: Hot Standby (v9d)

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.comPostgreSQL Training, Services and Support