Horton
Menu

Thread

  1. Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION

    Maxim Orlov <orlovmg@gmail.com> — 2025-11-27T16:00:30Z

    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.

-- 
Best regards,
Maxim Orlov.

  2. Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION

    Heikki Linnakangas <hlinnaka@iki.fi> — 2025-12-03T09:38:02Z

    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

  3. Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION

    Maxim Orlov <orlovmg@gmail.com> — 2025-12-03T10:50:59Z

    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.

  4. RE: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION

    Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> — 2025-12-03T12:27:06Z

    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

  5. Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION

    Maxim Orlov <orlovmg@gmail.com> — 2025-12-04T09:52:25Z

    On Wed, 3 Dec 2025 at 15:27, Hayato Kuroda (Fujitsu) <
kuroda.hayato@fujitsu.com> wrote:

> 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.
>
> OK, now I get it. Thank you very much for the explanation.

-- 
Best regards,
Maxim Orlov.