|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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).
|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|