Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Maxim Orlov <orlovmg(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION
Date: 2025-12-03 09:38:02
Message-ID: 88826d2e-476a-420c-8d6a-f4acfef8b57b@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Geier 2025-12-03 09:50:15 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Previous Message Mircea Cadariu 2025-12-03 08:59:18 Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication