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


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

Reply via email to