From: =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,  Pg Hackers
 <pgsql-hackers@lists.postgresql.org>
Subject: Re: reporting TID/table with corruption error
References: <202108191637.oqyzrdtnheir@alvherre.pgsql>
	<CAH2-WzmCLNK09r_C+A9ZxmmdZ2AjgDGyCJjVYWBun2LUws_gJw@mail.gmail.com>
Date: Thu, 19 Aug 2021 18:36:15 +0100
In-Reply-To: 
 <CAH2-WzmCLNK09r_C+A9ZxmmdZ2AjgDGyCJjVYWBun2LUws_gJw@mail.gmail.com>
	(Peter Geoghegan's message of "Thu, 19 Aug 2021 09:44:09 -0700")
Message-ID: <87y28xuyk0.fsf@wibble.ilmari.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
 <https://www.postgresql.org/message-id/87y28xuyk0.fsf%40wibble.ilmari.org>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:

> On Thu, Aug 19, 2021 at 9:38 AM Alvaro Herrera <alvherre@alvh.no-ip.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