Re: Representation of ResourceOwnerIds (transient XIDs) in system views (lazy xid assignment)

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