Re: Rework SLRU I/O errors handle - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Rework SLRU I/O errors handle
Date
Msg-id f2d1846e-04ac-43f5-9fdb-80d8e7daf49d@iki.fi
Whole thread Raw
In response to Re: Rework SLRU I/O errors handle  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On 11/03/2026 12:51, Heikki Linnakangas wrote:
> On 06/03/2026 19:08, Maxim Orlov wrote:
>> I don't know what's happening with my mail, but I haven't
>> received the previous letters.
>>
>> Anyway, v4 looks good to me.
>> Perhaps the extra double line following clog_errdetail_for_io_error
>> is unnecessary? But as always, to your taste.
> 
> Thanks. I did one more iteration on this: I realized that the error we 
> now printed for errors on pg_multixact/members always printed the 
> failing offset, whereas before this patch we usually printed the failing 
> *multixid* that the member is part of. Printing the multixid might 
> actually be more useful; the offset can more easily be deduced from the 
> segment filename and physical offset that is printed anyway, but it's 
> harder to know which multixid it belongs to. This printing the 
> originating multixid seems useful. If things go badly wrong and you need 
> to do manual debugging of a corrupted database, the multixid can more 
> easily be compared with the xmax in the heap and with pg_waldump output, 
> for example.
> 
> We can print both, per attached, which is even better. This is perhaps 
> overkill, but then again, if you hit an error like this, you really 
> appreciate any extra information you can get.

I hear no objections, so committed that. Thanks!

- Heikki




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD
Next
From: Fujii Masao
Date:
Subject: Re: [PATCH] Docs: clarify default values of EXPLAIN BUFFERS and SERIALIZE