Re: beta1 & beta2 & Windows & heavy load

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> From the example case it's not hard to imagine situations where
> we will want lots of subtransactions; just using exceptions in functions
> will implicitly open new ones! (This kind of bothers me because of the
> possibly very fast use of Xids, accelerating Xid counter wraparound ...)

Yeah, that's been bothering me too, but I don't see any easy way around
it. Without some major rethinking, a subxact has got to have its own
XID that it can put on tuples that it writes; else we cannot cope with
rollback of the subxact, which is rather the point after all...

However: using exceptions in functions is a good example of "trivial
subxacts" that aren't ever going to write any tuples; and so at least
in principle it might be possible to avoid assigning an XID to such
subxacts.

The idle thoughts I had about this were:

1. Do not assign an XID nor take a lock in StartSubTransaction; instead
set the xid field of the transaction state record to InvalidXid.

2. In GetCurrentTransactionId, check for InvalidXid; if seen, assign the
XID (and take the lock on it) before returning.

3. Skip the obvious things at subxact commit/abort time. A subxact that
has never called GetCurrentTransactionId has certainly never emitted a
tuple, so it need not have any record in WAL.

I can see a number of gotchas to this, but the ones I've thought of so
far all have plausible workarounds:

* I think some places assume that subxacts have XIDs >= their parent.
We could enforce this by requiring GetCurrentTransactionId to
recursively ensure that the parent has an XID before assigning one
to the child. This shouldn't cause any extra overhead for nested
"trivial transactions".

* We use the subxact ID for disambiguation of various modules'
per-subtransaction state. However a possible solution is already known
from the rewrite I recently did on trigger.c. It turned out in that
case to be equally convenient, if not more so, for the trigger module to
generate its own unique IDs for subtransactions (really more like
command counter values than XIDs). We could propagate the same concept
into the other modules that presently call GetCurrentTransactionId
without the intention of pushing the XID into the database.

So it seems potentially doable, but maybe it's the sort of thing that
had better wait for 8.1.

I will go ahead and make that change in lock release and
XactLockTableWait, though, since that's clearly a killer.

regards, tom lane