Re: cannot freeze committed xmax
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-10-28T15:25:31Z
Lists: 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 time ago. 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 transaction aborted. But the query of clog is saying that it committed. Something is wrong with that. How did the hint bits get 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've got corruption. Your question "preventing cutoff_xid to be greater than XID of some transaction which was aborted long time ago" seems to be ignoring that TransactionIdDidCommit(xid) is returning true, suggesting the transaction did not abort. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix pruning of locked and updated tuples.
- 9c2f0a6c3cc8 11.0 cited
-
Perform a lot more sanity checks when freezing tuples.
- 699bf7d05c68 11.0 cited