Re: beta1 & beta2 & Windows & heavy load

I wrote:
> We could revert to Alvaro's initial design in which subxacts didn't take
> out separate locks on their XIDs; this would make XactLockTableWait a
> lot slower though, and probably subject to unwanted deadlocks. You
> really want to release waiters for a subxact as soon as the subxact
> fails, rather than making them wait around for the parent.

> Right now I'm not seeing a cure that's not worse than the disease.

After awhile I thought of a possibly rather crocky solution:

1. During CommitSubTransaction, release the lock on the subtransaction's
XID (but not any of its other locks). This means that the number of
locks held due to just transaction XIDs is no more than the subxact
nesting depth, rather than growing with the number of subcommitted XIDs.

2. XactLockTableWait would have to do something like this:

for (;;)
{
wait for lock associated with xid;
if (!TransactionIdIsInProgress(xid))
break;
xid = SubTransGetParent(xid);
}

This relies on the fact that TransactionIdIsInProgress will return true
for subcommitted children of still-open parents, but not for aborted
children. So once we get past the wait, we check to see which case
applies, and wait for the subxact's parent if necessary. If the subxact
aborted then we need no longer wait.

I'm not totally convinced that this is race-condition-free, but I
haven't been able to poke a hole in it yet.

The other question is whether it's worth some extra overhead in
XactLockTableWait to save on shared memory. I'm inclined to think it
is, mainly because you don't get into XactLockTableWait in the first
place unless you're going to have to block. (I'm pretty sure all paths
leading to it have already determined that the other transaction is or
very recently was InProgress.) So you lose anyway, and losing a few
more microseconds isn't that big a deal.

Comments?

regards, tom lane