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

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 19:50:28
Message-ID: 46D5CE04.1020705@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2007-08-29 19:58:49 Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment
Previous Message Josh Berkus 2007-08-29 19:39:43 Re: [HACKERS] Contrib modules documentation online