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

"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> 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,

Yeah, we have to do that since there might not *be* an XID holding the
lock. But I still think the session ID would be sufficient here.
(Perhaps we don't need the PID either, although then we'd need to change
pg_stat_activity to provide session id as a join key...)

> .) On the left-hand side (The locked object), add a RID column of type int8,
> containing (2^32)*sessionID + localTransactionId.

I'm a bit uncomfortable with that since it renders the view completely
useless if you don't have a working int8 type.

> .) To prevent the int8 from being negative, we limit the sessionID to 31 bytes -
> which is still more then enough.

Hmm ... actually, that just begs the question of how many bits we need
at all. Could we display, say, 24 bits of sessionID and 8 bits of
localXID merged into a column of nominal XID type? There's a
theoretical risk of false join matches but it seems pretty theoretical,
and a chance match would not break any system functionality anyway since
all internal operations would be working with full-width counters.

regards, tom lane