Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.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...)
Yeah, the PID seems to be redundant if we add the RID. But OTOH it does no
harm to leave it there - other than the xid, which gives a false sense
of security. Don't know what our policy for system-catalog
backwards-compatibility is, though...
>> .) 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.
Yeah, I only now realized that int8 really *is* busted if INT64_IS_BUSTED is
defined. I always thought that there is some kind of emulation code in place,
but apparently there isn't. :-( So there goes this idea....
>> .) 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.
Hm.. If we go down that router, we could just calculate some hash value
from sessionID and localTransactionId that fits into 31 bits, and use
an int4. Or 32 bits, and use xid.
I am, however a bit reluctant to do this. I'd really hate to spend a few hours
tracking down some locking problem, only to find out that I'd been looking at
the wrong place because of some id aliasing... I know it's only a 1-in-4-billion
chance, but still.... it gives me an uneasy feeling.
What about a string representation? Something like sessionId/localTransactionId?
Should we ever decide that indeed this *should* get it's own datatype, a string
representation would allow for a very painless transition...
greetings, Florian Pflug
