Re: New strategies for freezing, advancing relfrozenxid early - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: New strategies for freezing, advancing relfrozenxid early
Date
Msg-id CAH2-Wz=zr8MGS_EbCtoeYuOuRSV+DopDfu5cDP0yVgauqOXkLw@mail.gmail.com
Whole thread Raw
In response to RE: New strategies for freezing, advancing relfrozenxid early  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Responses RE: New strategies for freezing, advancing relfrozenxid early  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: An oversight in ExecInitAgg for grouping sets
Next
From: Dilip Kumar
Date:
Subject: Re: Exit walsender before confirming remote flush in logical replication