| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: New strategies for freezing, advancing relfrozenxid early |
| Date: | 2022-12-27 07:30:25 |
| Message-ID: | CAH2-Wz=zr8MGS_EbCtoeYuOuRSV+DopDfu5cDP0yVgauqOXkLw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 26, 2022 at 10:57 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2022-12-27 07:40:05 | Re: Exit walsender before confirming remote flush in logical replication |
| Previous Message | Richard Guo | 2022-12-27 07:12:17 | Re: An oversight in ExecInitAgg for grouping sets |