Re: cannot freeze committed xmax - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: cannot freeze committed xmax
Date
Msg-id 8B2560FC-F92D-46A4-8D71-EA274B5A56FC@enterprisedb.com
Whole thread Raw
In response to cannot freeze committed xmax  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: cannot freeze committed xmax
List pgsql-hackers

> On Oct 28, 2020, at 6:44 AM, Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote:
>
> Looks like there is no assumption that xmax should be set to InvalidTransactionId when HEAP_XMAX_INVALID bit is set.
> And I didn't find any check  preventing cutoff_xid to be greater than XID of some transaction which was aborted long
timeago. 

Nothing in your example suggests that cutoff_xid is wrong, so I'd assume that part is probably working ok.

Your data shows that HEAP_XMAX_INVALID and HEAP_UPDATED flags are both set.  That should only happen if the updating
transactionaborted.  But the query of clog is saying that it committed. Something is wrong with that.  How did the hint
bitsget set to HEAP_XMAX_INVALID if the transaction did commit.  Either some process is setting that hint bit when it
shouldn't,or your clog is corrupted and returning a bogus answer about the xmax having been committed.  Either way,
you'vegot corruption. 

Your question "preventing cutoff_xid to be greater than XID of some transaction which was aborted long time ago" seems
tobe ignoring that TransactionIdDidCommit(xid) is returning true, suggesting the transaction did not abort. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: cutting down the TODO list thread
Next
From: John Naylor
Date:
Subject: Re: duplicate function oid symbols