Re: New strategies for freezing, advancing relfrozenxid early

On Mon, Dec 26, 2022 at 10:57 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
> I guessed that this assertion failure seemed to be caused by the commit 4ce3af[2],
> because the Assert() seemed to be added by the commit.

I agree that the problem is with this assertion, which is on the
master branch (not in recent versions of the patch series itself)
following commit 4ce3af:

else
{
    /*
    * Freeze plan for tuple "freezes xmax" in the strictest sense:
    * it'll leave nothing in xmax (neither an Xid nor a MultiXactId).
    */
    ....
    Assert(MultiXactIdPrecedes(xid, cutoffs->OldestMxact));
    ...
}

The problem is that FRM_INVALIDATE_XMAX multi processing can occur
both in Multis from before OldestMxact and Multis >= OldestMxact. The
latter case (the >= case) is far less common, but still quite
possible. Not sure how I missed that.

Anyway, this assertion is wrong, and simply needs to be removed.
Thanks for the report
-- 
Peter Geoghegan