| 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
| 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 |