Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION |
| Дата | |
| Msg-id | 88826d2e-476a-420c-8d6a-f4acfef8b57b@iki.fi обсуждение исходный текст |
| Ответ на | Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION (Maxim Orlov <orlovmg@gmail.com>) |
| Ответы |
Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION
|
| Список | 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
В списке pgsql-hackers по дате отправления: