Re: reporting TID/table with corruption error

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: reporting TID/table with corruption error
Дата
Msg-id F412B035-AF83-40C6-BA0A-4C7AA810091E@enterprisedb.com
обсуждение исходный текст
Ответ на Re: reporting TID/table with corruption error  (Andrey Borodin <x4mmm@yandex-team.ru>)
Ответы Re: reporting TID/table with corruption error  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers

> On Aug 19, 2021, at 10:17 AM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> It would be great to see relation, block, offset, xmin\xmax and, probably, flags whenever
ERRCODE_DATA_CORRUPTED\ERRCODE_INDEX_CORRUPTEDis used. Iif it's possible to extract this information, of cause. This is
neededespecially in amcheck functions. 

blockno, offnum and attnum are already included in every result for amcheck functions over heap relations, though
attnummay be null if the corruption is not specific to any particular column. 

xmin, xmax and various flags may occur in the corruption message if they are relevant, but they are not always present.

There was some disagreement during the development of verify_heapam on this point.  We went with the idea that the user
couldfind and inspect the corrupt data with another tool if they had the (blockno, offnum, attnum) information.  As
such,it wasn't necessary to include all the data in the output. 

It shouldn't be too complicated to have a second interface that returns all of the 23 byte main table tuple header
informationand also the 23 byte toast tuple header (when relevant) along with the corruption message.  The guts of the
corruptioncheck would be shared between the two interfaces.  I haven't tried writing a patch yet, but it seems the
patchshouldn't be terribly complicated. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






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

Предыдущее
От: Dagfinn Ilmari Mannsåker
Дата:
Сообщение: Re: reporting TID/table with corruption error
Следующее
От: John Naylor
Дата:
Сообщение: Re: badly calculated width of emoji in psql