Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Since generating transient XIDs (named ResourceOwnerIDs in my patch, since
their lifetime is coupled to the lifetime of a transaction's toplevel
resource owner) seems to be to way to go for lazx xid assignment, I need
to find a way to represent them in the pg_locks view.
This is going very far towards gilding the lily. Try to avoid loading
the patch down with a new datatype.
I'm inclined to think that it'd be sufficient to show the high half of
the ID (that is, the session number) in pg_locks, because there will
never be cases where there are concurrently existing locks on different
localTransactionIds.
Hm.. I'm not too happy with that. I you for example join pg_locks to
pg_stat_activity (which would need to show the RID too), than you
*might* get a bogus result if a transaction ends and a new one starts
on the same backend between the time pg_lock_status is called, and the time
the proc array is read.
This could probably be displayed in the
transactionID columns, which would mean we're abusing the user-visible
xid datatype, but I don't see much harm in it.
I'm even more unhappy with that, because the session id of a RID might
coincide with a currently in-use XID.
What about the following.
.) Remove the right-hand side XID from pg_locks (The one holder or waiter
of the lock). It seems to make more sense to store a RID here, and let
the user fetch the XID via a join to pg_stat_activity. We could also show
both the XID (if set) and the RID, but that might lead people to believe
that their old views or scripts on top of pg_locks still work correctly
when they actually do not.
.) On the left-hand side (The locked object), add a RID column of type int8,
containing (2^32)*sessionID + localTransactionId.
.) To prevent the int8 from being negative, we limit the sessionID to 31 bytes -
which is still more then enough.
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
