On Mon, 2009-01-12 at 14:10 +0200, Heikki Linnakangas wrote: > > However, I think XactLockTableWait() doesn't need to know the parent > > either. (This feels more like wishful thinking, but here goes anyway). > > We release locks *after* TransactionIdAbortTree() has fully executed, so > > the test for TransactionIdIsInProgress(xid) will always see the abort > > status, if set. Notice that if we are awake at all it is because the > > top-level transaction is complete or our subxid is aborted. So there is > > never any need to look at the status of the parent, nor in fact any need > > to look at the procarray at all, which is always a waste of effort. > > Right, we don't currently write a WAL record at subtransaction commit, > only at subtransaction abort or top-level commit. So the problem > described in the comment at XactLockTableWait() can't arise in the standby.
Good. So we can exclude parent_xid and just include top level xid. So we are now officially back inside the current xlog record padding: we don't need to increase WAL record length and therefore we can lose slotid (yay!). > Actually, I wonder if we should write a WAL record at subtransaction > commit too, to save on shared memory in the standby as well. You understand that the current design never performs XactLockTableInsert() for individual top/sub transactions? There would be no memory overhead to save. The only locks allowed are AccessShareLocks which never conflict with anything except for AccessExclusiveLocks. If an AEL conflicts with an ASL we blow away the ASL holders. If an ASL requestor is blocked by a an AEL the wait is performed on the single lock table entry for the Startup process, which acts as a proxy for all emulated AEL lock holders. > > If > > you believe that, you'll want to commit the attached patch (or something > > similar with comments refactored etc). > > Umm, we still need the SubTransGetParent() call in normal operation. OK, that was really just a thought experiment anyway to prove the point one way or the other. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
