Re: reporting TID/table with corruption error

From: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: reporting TID/table with corruption error
Date: 2021-08-19 17:36:15
Message-ID: 87y28xuyk0.fsf@wibble.ilmari.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <pg(at)bowt(dot)ie> writes:

> On Thu, Aug 19, 2021 at 9:38 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> A customer recently hit this error message:
>>
>> ERROR: t_xmin is uncommitted in tuple to be updated
>>
>> This was not very informative, so without any clues, we had to let it
>> go. But it did occur to me that we can improve this message so that we
>> know details such as the TID and the relation that caused the issue, so
>> that if it ever occurs again we can at least look at the WAL stream for
>> anything affecting the tuple, maybe it'd help to understand the problem.
>
> I think that this is a very good idea. Ideally this stuff would be
> more standardized.

There are various functions for adding auxilliary fields to the error
report, e.g. errtable() for the schema and table names, but that only
seems to be reported to the client, not logged on the server.

Should we be logging auxiliary error fields? If not by default, maybe
by a higher log_error_verbosity level (possibly a new one between
default and verbose).

- ilmari

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-08-19 17:49:09 Re: reporting TID/table with corruption error
Previous Message Andrey Borodin 2021-08-19 17:28:40 Re: reporting TID/table with corruption error