Re: Hot standby, slot ids and stuff

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