Representation of ResourceOwnerIds (transient XIDs) in system views (lazy xid assignment) - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Representation of ResourceOwnerIds (transient XIDs) in system views (lazy xid assignment)
Date
Msg-id 46D5BE2E.6000805@phlo.org
Whole thread Raw
Responses Re: Representation of ResourceOwnerIds (transient XIDs) in system views (lazy xid assignment)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi

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.

ResourceOwnerIds are a structure composed of two uint32s, a processID
(could be the PID of the backend, but to make sure that it isn't reused
too quickly, it's actually a synthentic ID generated at backend start),
and localTransactionId which is just incremented whenever a new transaction
is started in a backend. This design was the result of my discussion with
Tom - it's main advantage is that it needs no lock to generate a new
ResourceOwnerId.

I see 3 possibilities to represent this in system views
A) Make ResourceOwnerID a full-blown type, with in and out methods, very   similar to tids.
"processId/localTransactionId"would be a natural   string representation.
 
B) Just convert the ResourceOwnerId into a string in pg_lock_status.   Looks quite similar to (A) from a user's point
ofview, but the   implementation is much shorter.
 
C) Combine the two uint32 fields of ResourceOwnerId into a int8.   Might be more efficient than (B). The main
disadvantageis that   some ResourceOwnerIds will be represented by *negative* integers,   which is pretty ugly.
 
D) Just make them two int4 fields. This has the same "negativity"   issue that (C) has, and might cause confusion if
usersdon't   read the docs carefully.
 

I'm leaning towards (A), but it adds a lot new code (although most if
it would be copied nearly 1-to-1 from tid.c) for maybe too little gain.

If (A) is deemed not appropriate, doing (C) and restricting processIds
to <= 0x80000000 might be an option.

greetings, Florian Pflug



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment
Next
From: "Florian G. Pflug"
Date:
Subject: Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment