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-11T10:51:53Z
Lists: pgsql-hackers

Attachments

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

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