| From: | Maxim Orlov <orlovmg(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION |
| Date: | 2025-12-03 10:50:59 |
| Message-ID: | CACG=ezZwGXu39-fiBEjJPR8uYv5Ar7QY0F-oxNfFXm_e60jxmQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 3 Dec 2025 at 12:38, Heikki Linnakangas <hlinnaka(at)iki(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2025-12-03 10:54:39 | Re: List TAP test files in makefiles |
| Previous Message | Peter Eisentraut | 2025-12-03 10:41:20 | Re: Collation & ctype method table, and extension hooks |