Message-ID: <5b4e458d-94f1-4ca3-ab72-aae8328e038d@iki.fi>
Date: Fri, 20 Feb 2026 15:37:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: POC: make mxidoff 64 bits
To: Maxim Orlov <orlovmg@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>,
 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Alexander Korotkov <aekorotkov@gmail.com>, wenhui qiu
 <qiuwenhuifx@gmail.com>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
References: <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com>
 <36531c0e-292c-409d-bbc7-a252cf6e910a@iki.fi>
 <54aa8f65-f0e4-4464-b543-e0399c1cab1e@iki.fi>
 <CACG=ezYUJSvnuxntkURNWo_1vZ+AtmcQfqd_h6WgDzGaudfw+Q@mail.gmail.com>
 <4a9dda70-0af7-41a4-9636-b168f2fc48ef@iki.fi>
 <46cc45e9-fddd-44bc-bcb3-96889aafd921@iki.fi>
 <CAExHW5tUEkiQrvm9hgccjKUNkWBnJ5_HDUrAwiHBTxu+Vuj29Q@mail.gmail.com>
 <6c298bc4-7029-4c1d-bf16-3e094842ce32@iki.fi>
 <CAExHW5t3kzJiVqmoqCLyGmfkTjD4Rwa27kXH-S_XvHWLkM2fzw@mail.gmail.com>
 <CAExHW5ucnoyjd6p7UVVhQTeV7hc8-vX81ti8f7sU0COqfUWzQg@mail.gmail.com>
 <2c62322e-a0e3-49cd-b369-370718a8efd8@iki.fi>
 <CAExHW5s_uNeD_xYjdbSR8khMXwWJQOY9Qg=j4T+5KOfGz5-RsQ@mail.gmail.com>
 <3624730d-6dae-42bf-9458-76c4c965fb27@iki.fi>
 <b7faf07c-7d2c-4f35-8c43-392e057153ef@gmail.com>
 <cbbbb5ae-0219-4c67-a52b-fa03119f6701@iki.fi>
 <6dc0880b-15fb-42cf-abfc-62d9d80dd287@iki.fi>
 <CACG=ezbwy1zargXDNPeYXxZwRW3jXu_aD=rcG-7dc4fw7Y9Ojw@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <CACG=ezbwy1zargXDNPeYXxZwRW3jXu_aD=rcG-7dc4fw7Y9Ojw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/5b4e458d-94f1-4ca3-ab72-aae8328e038d%40iki.fi>
Precedence: bulk

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