Re: subtransaction assert failure

Neil Conway <neilc(at)samurai(dot)com> writes:
> I'm seeing an intermittent assertion failure while running "make check"
> with current sources.

> TRAP: FailedAssertion("!(TransactionIdFollowsOrEquals(xid,
> RecentXmin))", File:
> "/Users/neilc/pgsql/src/backend/access/transam/subtrans.c", Line: 146)

Hmm, I haven't seen this myself but I see what's causing it --- sloppy
thinking about the role of RecentXmin. We need another variable named
something like TransactionXmin, which would be the RecentXmin first
computed during the current transaction. (This would be a copy of
MyProc->xmin; we could just look directly at that but I think I prefer
a separate backend-local variable.) The tests that protect access to
pg_subtrans need to use this, not RecentXmin, as the cutoff point.

The problem of course is that RecentXmin is the xmin associated with the
most recently computed snapshot, but there may be older snapshots still
in use in the transaction. The time qual test code needs to be able to
get answers for transactions that could be present in any of the
transaction's snapshots, not only the most recent.

Mea culpa, will fix.

regards, tom lane

PS: this points up once again that the regression tests do not do very
well at testing concurrent behavior. We need to think about some sort
of parallel-test harness that would let us write tests that have better
odds of catching bugs like this.