Re: Rework SLRU I/O errors handle

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Rework SLRU I/O errors handle
Дата
Msg-id 511e3a69-da70-4bb2-9185-c93d3af8fdf5@iki.fi
обсуждение исходный текст
Ответ на Re: Rework SLRU I/O errors handle  (Maxim Orlov <orlovmg@gmail.com>)
Ответы Re: Rework SLRU I/O errors handle
Список 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

Вложения

В списке pgsql-hackers по дате отправления: