Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Representation of ResourceOwnerIds (transient XIDs) in system views (lazy xid assignment)
Date: 2007-08-29 22:18:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"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

In response to


pgsql-hackers by date

Next:From: Neil ConwayDate: 2007-08-29 22:22:11
Subject: Re: int8 & INT64_IS_BUSTED
Previous:From: Scott MarloweDate: 2007-08-29 21:26:58
Subject: Re: [HACKERS] Contrib modules documentation online

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group