| From: | Maxim Orlov <orlovmg(at)gmail(dot)com> |
|---|---|
| To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION |
| Date: | 2025-11-27 16:00:30 |
| Message-ID: | CACG=ezYRM-qKnQdYvt+M-AiW7ziwBF54r4MKmFQj5o0TnRtniA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2025-11-27 16:40:18 | Re: weird ON CONFLICT clauses |
| Previous Message | Álvaro Herrera | 2025-11-27 16:00:24 | weird ON CONFLICT clauses |