Re: pg_subtrans and WAL - Mailing list pgsql-hackers

On Fri, Aug 20, 2004 at 01:36:39PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > On Tue, Aug 10, 2004 at 12:24:06PM -0400, Tom Lane wrote:
> >> It may be that we do not care because pg_subtrans doesn't have to be
> >> valid after a crash, but I haven't seen any proof of that theory.
> 
> > The whole point of the subtrans info is to be available _while_ the
> > transaction tree is running.  If there is a crash, then by definition no
> > backend can be running when we return, so pg_subtrans info is useless at
> > that point.  We only need pg_clog to be correct.
> 
> But we also have to be sure that we don't try to access the useless info
> anyway.

Hmm.  I've skimmed over callers of TransactionIdDid{Commit,Abort} and
they are in the following places:

- tqual.c (all after TransactionIdIsInProgress)
- heapam.c (all after XactLockTableWait)
- one in xact.c (while aborting, assert that it isn't committed)
- one in xlog.c (in #ifdef UNDO)

- lmgr.c (in XactLockTableWait)
- two in xlogutils.c

Those last two are the ones that could cause trouble; I think the others
are safe.  Actually I'm not sure what the ones in xlogutils.c are about.

> For instance some pre-crash subxacts might remain marked SUBCOMMITTED
> in clog indefinitely.  I think this could be worked around: for
> example, TransactionIdDidCommit could assume that any SUBCOMMITTED
> xact older than RecentGlobalXmin must represent a child of a crashed
> parent.

This would be a slight modification.  sinval.c needs to export
RecentGlobalXmin, and TransactionIdDidCommit check it.  It's a small
change AFAICS.  Do you want me to submit a patch?

> The point is that the behaviors are fundamentally different.  We have no
> need for any WAL log entries for pg_subtrans; we should never fsync it;
> and the rules for deciding when and where to truncate it are a lot
> different (or at least should be different).  I thought from the
> beginning that the slru layer underneath pg_clog was bad from the point
> of view of obfuscating the code, because it forced an awkward division
> of labor between clog.c and slru.c.  Now that I realize that there's not
> that much behavior that we really want to share, I wonder whether we
> shouldn't revert that change and make subtrans.c stand on its own.

Maybe you are right.  I think this is a bigger change and it's not badly
needed, so it can wait to 8.1.  Do you agree?

> > On a related note: if we mark a Xid with SUBTRANS COMMIT and later crash
> > without updating it, the main Xid will remain in in-progress status.  At
> > what point is it marked aborted?
> 
> I do not think there's any guarantee that it ever will be so marked.
> Certainly it could be a very long time until someone exhibits any
> interest in that particular Xid's status...

Right, that's what I thought.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Granting software the freedom to evolve guarantees only different results,
not better ones." (Zygo Blaxell)