Re: Rework SLRU I/O errors handle

Heikki Linnakangas <hlinnaka@iki.fi>

From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Maxim Orlov <orlovmg@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-03-13T14:32:10Z
Lists: 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




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add callback for I/O error messages in SLRUs