On Mon, Oct 09, 2017 at 05:19:11PM -0700, Peter Geoghegan wrote: > On Sun, Oct 16, 2016 at 6:46 PM, Noah Misch <n...@leadboat.com> wrote: > > - Verify agreement between CLOG, MULTIXACT, and hint bits. > > This is where it gets complicated, I think. This is what I really want > to talk about. > > The recent commit 20b65522 pretty clearly established that a tuple > could technically escape freezing (having HEAP_XMIN_FROZEN set) > despite actually being before a relfrozenxid cut-off. The idea was > that as long as we reliably set hint bits on heap-only tuples through > WAL-logging, it doesn't matter that their CLOG could be truncated, > because nobody will ever need to interrogate the CLOG anyway (to coin > a phrase, the heap-only tuple nevertheless still had its xmax > "logically frozen"). If nothing else, this leaves me with a very > squishy set of invariant conditions to work with when I go to verify > agreement with CLOG, MULTIXACT, and hint bits. > > So, the question is: What is the exact set of invariant conditions > that I can check when I go to verify agreement between a heap relation > and the various SLRUs? In particular, at what precise XID-wise point > do CLOG and MULTIXACT stop reliably storing transaction status? And, > is there a different point for the xmax of tuples that happen to be > heap-only tuples? > > Another important concern here following 20b65522 is: Why is it safe > to assume that nobody will ever call TransactionIdDidCommit() for > "logically frozen" heap-only tuples that are not at the end of their > HOT chain, and in so doing get a wrong answer? I can't find a rule > that implies that there is no dangerous ambiguity that's written down > anywhere. I *can* find a comment that suggests that it's wrong, though > -- the "N.B." comment at the top of heap_prepare_freeze_tuple(). > (Granted, that comment doesn't seem to acknowledge the fact that the > caller does WAL-log as part of freezing; there has been some churn in > this area.)
All good questions; I don't know offhand. Discovering those answers is perhaps the chief labor required of such a project. The checker should consider circumstances potentially carried from past versions via pg_upgrade. Fortunately, if you get some details wrong, it's cheap to recover from checker bugs. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers