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

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Representation of ResourceOwnerIds (transient XIDs) in system views (lazy xid assignment)
Date: 2007-08-29 18:42:54
Message-ID: 46D5BE2E.6000805@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 of view, 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 disadvantage is 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 users don'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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2007-08-29 19:04:02 Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment
Previous Message Tom Lane 2007-08-29 18:38:52 Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment