"Florian G. Pflug" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster