Simon Riggs wrote:
Rather than store the
parent xid itself we store the difference between the current xid and
the parent xid. Typically this will be less than 65535; when it is not
we set it to zero but issue an xid assignment xlog record.
That sounds pretty hacky.
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.
Actually, I wonder if we should write a WAL record at subtransaction
commit too, to save on shared memory in the standby as well.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
