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

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 (view raw or flat)
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

pgsql-hackers by date

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

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