On 2022-Jan-10, Andrey Borodin wrote:
> 3. The tuple seems to be updated in a high-contention concurrency
> trigger function, autovacuum keeks in ~20-30 seconds after the message
> in logs
Hmm, I bet this is related.
> [ 2022-01-10 09:07:17.671 MSK [unknown],,_s,310759,XX001
> 19 авг. 2021 г., в 21:37, Alvaro Herrera написал(а):
>
> A customer recently hit this error message:
>
> ERROR: t_xmin is uncommitted in tuple to be updated
Hi!
Currently I'm observing this on one of our production clusters. The problem
occurs at random points in time, seems to be
Pushed to all branches, thanks.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
> 19 авг. 2021 г., в 23:19, Mark Dilger
> написал(а):
>
>
>
>> On Aug 19, 2021, at 10:57 AM, Peter Geoghegan wrote:
>>
>> High
>> verbosity makes a lot of sense here.
>
> Works for me. We could create another function, "verify_heapam_full"
> perhaps, that returns additional columns
> On Aug 19, 2021, at 10:57 AM, Peter Geoghegan wrote:
>
> High
> verbosity makes a lot of sense here.
Works for me. We could create another function, "verify_heapam_full" perhaps,
that returns additional columns matching those from pageinspect's
heap_page_items():
OUT lp smallint,
On Thu, Aug 19, 2021 at 10:49 AM Mark Dilger
wrote:
> 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.
> On Aug 19, 2021, at 10:17 AM, Andrey Borodin 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
>
Peter Geoghegan writes:
> On Thu, Aug 19, 2021 at 9:38 AM Alvaro Herrera
> 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
> 19 авг. 2021 г., в 21:37, Alvaro Herrera написал(а):
>
> A customer recently hit this error message:
>
> ERROR: t_xmin is uncommitted in tuple to be updated
Sorry for one more message, it occurred to me only after sending previous one
that I know this exact message.
We encountered this
> 19 авг. 2021 г., в 21:44, Peter Geoghegan написал(а):
>
> I think that this is a very good idea. Ideally this stuff would be
> more standardized.
+1
It would be great to see relation, block, offset, xmin\xmax and, probably,
flags whenever ERRCODE_DATA_CORRUPTED\ERRCODE_INDEX_CORRUPTED is
On Thu, Aug 19, 2021 at 9:38 AM Alvaro Herrera 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
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
12 matches
Mail list logo
