Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> 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
tostore a RID here, and let the user fetch the XID via a join to pg_stat_activity. We could also show both the XID
(ifset) and the RID, but that might lead people to believe that their old views or scripts on top of pg_locks still
workcorrectly 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
