From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: reporting TID/table with corruption error
Date: Thu, 19 Aug 2021 10:49:09 -0700
Message-ID: <F412B035-AF83-40C6-BA0A-4C7AA810091E@enterprisedb.com> (raw)
In-Reply-To: <924415DA-A514-4B67-AC66-E3D6C5F13F89@yandex-team.ru>
References: <202108191637.oqyzrdtnheir@alvherre.pgsql>
<CAH2-WzmCLNK09r_C+A9ZxmmdZ2AjgDGyCJjVYWBun2LUws_gJw@mail.gmail.com>
<924415DA-A514-4B67-AC66-E3D6C5F13F89@yandex-team.ru>
> 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_CORRUPTED is used. Iif it's possible to extract this information, of cause. This is needed especially in amcheck functions.
blockno, offnum and attnum are already included in every result for amcheck functions over heap relations, though attnum may 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 could find 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 information and also the 23 byte toast tuple header (when relevant) along with the corruption message. The guts of the corruption check would be shared between the two interfaces. I haven't tried writing a patch yet, but it seems the patch shouldn't be terribly complicated.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: mark.dilger@enterprisedb.com, x4mmm@yandex-team.ru, pg@bowt.ie, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Subject: Re: reporting TID/table with corruption error
In-Reply-To: <F412B035-AF83-40C6-BA0A-4C7AA810091E@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox