Re: Rework SLRU I/O errors handle
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Rework SLRU I/O errors handle |
| Дата | |
| Msg-id | f2d1846e-04ac-43f5-9fdb-80d8e7daf49d@iki.fi обсуждение |
| Ответ на | Re: Rework SLRU I/O errors handle (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Список | 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 по дате отправления: