Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION - Mailing list pgsql-hackers

From Maxim Orlov
Subject Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION
Date
Msg-id CACG=ezZwGXu39-fiBEjJPR8uYv5Ar7QY0F-oxNfFXm_e60jxmQ@mail.gmail.com
Whole thread Raw
In response to Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses RE: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION
List pgsql-hackers

On Wed, 3 Dec 2025 at 12:38, Heikki Linnakangas <hlinnaka@iki.fi> wrote:

Even with 64-bit XIDs, you can't have transactions older than 2^31 still
running, right? So AFAICS you can continue using 32-bit XID in LOCKTAG.


Actually, I can, and some brave people do just that. Although it is bad
for a number of reasons. The issue is that I can't put on the same page
tuples with XIDs that differ by more than 2^31 using the current design
(with storing the XIDs "base" on the page). That is why I start thinking
about "real" 64-bit XIDs.

As for my original question, I think, the reason to have MyDatabaseId
in the LOCKTAG is that it's cheaper to store it in the lock, than try to
get it "on demand" in pg_lock_status() call by invoking
GetSubscription().
 
--
Best regards,
Maxim Orlov.

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Collation & ctype method table, and extension hooks
Next
From: Peter Eisentraut
Date:
Subject: Re: List TAP test files in makefiles