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 511e3a69-da70-4bb2-9185-c93d3af8fdf5@iki.fi
Whole thread Raw
In response to Re: Rework SLRU I/O errors handle  (Maxim Orlov <orlovmg@gmail.com>)
List pgsql-hackers
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.

- Heikki

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Define DatumGetInt8 function.
Next
From: Henson Choi
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)