Re: [WIP PATCH] Lazily assign xids for toplevel Transactions

"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> I've spent the last few days factoring out that work, and turning it into
> a general solution. The result is this patch, which basically does the following

> .) It defines a special TemporaryTransactionId that is used as an xact's xid
> until the xact calls GetCurrentTransactionId / GetTopTransactionId.

[ squint... ] Why do you need that? The behavior we use with
subtransactions is just to leave the XID as InvalidOid until there's
a reason to assign it, and I think we should do the same with top-level
XIDs. Having an extra TemporaryTransactionId seems ugly, mainly because
it's not clear how XID comparison should handle it.

To leave XID at 0, you will need to teach GetSnapshotData and maybe
some other places that a proc could be advertising nonzero xmin even
when its XID is still 0. This does not seem like a big problem though.

> .) Each transaction get an "rid" (ResourceOwnerId) assigned when it starts, and
> obtains a lock on that rid, similar to how the xid is locked. This can
> be used to wait for a transaction's toplevel resource owner to release all
> it's locks, and serves as a unique identifier for a running transaction.

This seems like inventing a concept we could do without, also overhead
we could do without (assigning globally unique RIDs would require as
much mechanism and contention as XID assignment does). What about
locking the backend's PID instead? I do not see that long-term
uniqueness is needed, we just want to be able to wait for the backend's
current transaction to end.

If you do think it's important to distinguish the other guy's current
and next transaction (which maybe it is), then possibly we could lock a
combination of the PID and a *local*, per-backend transaction counter
(there should be plenty of room in LOCKTAG for this). This counter
value would have to be advertised in PGPROC, but there wouldn't be any
contention involved to assign a new value.

It's slightly annoying that this scheme involves taking two lmgr locks
per read-write transaction. I wonder whether we couldn't dispense with
the notion of locking one's XID per se. This would mean that where we
try to wait for another transaction by XID, we have to trawl through
the ProcArray to find that XID and see what PID/localID it maps to;
but if we're in that path we're already going to be blocking, so more
cycles there might be a good tradeoff for fewer cycles in transaction
start.

> 1) The second waiting phase of concurrent index builds fail to wait for xacts
> that haven't been assigned an XID when the reference shapshot was taken.
> The "rid" doesn't help here, because it's not currently store in the
> snapshot.

We'd probably want to whack that around so that it pays attention to the
xmins advertised by other backends, rather than their XIDs. This is
just a handwave though.

> 2) I'm not entirely sure yet how to handle two flags MyXactMadeTempRelUpdates,
> MyXactMadeXLogEntry and the MyRecPtr variable. Those seems to be made
> partly redundant by this patch - checking if an xact has a
> permanent xid assigned already tells if the transaction made any writes.

Yeah, it should be impossible for those to be set in a transaction that
hasn't assigned itself an xid.

regards, tom lane