On Mon, Oct 09, 2017 at 05:19:11PM -0700, Peter Geoghegan wrote:
> On Sun, Oct 16, 2016 at 6:46 PM, Noah Misch <noah@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