Обсуждение: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION
Hi!
While working on a patch to implement 64-bit transaction IDs in
PostgreSQL, I ran into a small problem. The
LockApplyTransactionForSession/UnlockApplyTransactionForSession
functions utilize the SET_LOCKTAG_APPLY_TRANSACTION macro, which
assumes XIDs are 32-bits.
In my case, the transaction IDs are growing twice as large, and we don't
have enough space to store them. I could simply resize the LOCKTAG
structure, extending it by 32 bits, but this is not the best solution.
However, I noticed that the MyDatabaseId field in
SET_LOCKTAG_APPLY_TRANSACTION appears unnecessary. As far as I
understand, the suboid should already uniquely identify the
subscription. Is the MyDatabaseId field truly necessary? Will only the
suboid suffice? I would be pleased to hear your thoughts on this.
PostgreSQL, I ran into a small problem. The
LockApplyTransactionForSession/UnlockApplyTransactionForSession
functions utilize the SET_LOCKTAG_APPLY_TRANSACTION macro, which
assumes XIDs are 32-bits.
In my case, the transaction IDs are growing twice as large, and we don't
have enough space to store them. I could simply resize the LOCKTAG
structure, extending it by 32 bits, but this is not the best solution.
However, I noticed that the MyDatabaseId field in
SET_LOCKTAG_APPLY_TRANSACTION appears unnecessary. As far as I
understand, the suboid should already uniquely identify the
subscription. Is the MyDatabaseId field truly necessary? Will only the
suboid suffice? I would be pleased to hear your thoughts on this.
--
Best regards,
Maxim Orlov.
On 27/11/2025 18:00, Maxim Orlov wrote: > Hi! > > While working on a patch to implement 64-bit transaction IDs in > PostgreSQL, I ran into a small problem. The > LockApplyTransactionForSession/UnlockApplyTransactionForSession > functions utilize the SET_LOCKTAG_APPLY_TRANSACTION macro, which > assumes XIDs are 32-bits. > > In my case, the transaction IDs are growing twice as large, and we don't > have enough space to store them. I could simply resize the LOCKTAG > structure, extending it by 32 bits, but this is not the best solution. > > However, I noticed that the MyDatabaseId field in > SET_LOCKTAG_APPLY_TRANSACTION appears unnecessary. As far as I > understand, the suboid should already uniquely identify the > subscription. Is the MyDatabaseId field truly necessary? Will only the > suboid suffice? I would be pleased to hear your thoughts on this. 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. - Heikki
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
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.
Dear Maxim, I recalled my post [1]. The database id is helpful when we output lock information by DescribeLockTag(). Since it would be called when the system might be under the deadlock, any locks should not be acquired even AccessShare. It can be done if catcache is missed. [1]: https://www.postgresql.org/message-id/TYAPR01MB5866E4B208BFAAA5A05B1EECF53F9%40TYAPR01MB5866.jpnprd01.prod.outlook.com Best regards, Hayato Kuroda FUJITSU LIMITED