Re: POC: make mxidoff 64 bits

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Maxim Orlov <orlovmg(at)gmail(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: POC: make mxidoff 64 bits
Date: 2026-02-20 13:37:48
Message-ID: 5b4e458d-94f1-4ca3-ab72-aae8328e038d@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20/02/2026 10:47, Maxim Orlov wrote:
>
> Just one more minor thing. While working on making CLOG 64-bit, I
> noticed that read error messages from SLRU pages were reported only in
> 32-bit format, with the upper half simply truncated. Here's a small
> patch to fix this problem. I used the "%u:%u" format because it is
> already used by Postgres for outputting 64-bit transactions.

Hmm, that's a prettya misleading format for multixid member offsets. And
for CLOG and other SLRUs too, as they will always show the epoch as 0.

This isn't really a new issue though, the SLRU errors have always said
"transaction %u", even for multixids and offsets, and that's always been
a little bogus. And for the pg_async SLRU, we just pass
InvalidTransactionId.

Can we improve the message with a callback or something, so that it's
more relevant for the SLRU?

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mahendra Singh Thalor 2026-02-20 14:10:36 Re: Non-text mode for pg_dumpall
Previous Message Ilia Evdokimov 2026-02-20 13:28:57 Re: Reduce planning time for large NOT IN lists containing NULL