Re: race condition in pg_class - Mailing list pgsql-hackers

From Robert Haas
Subject Re: race condition in pg_class
Date
Msg-id CA+TgmoZocjvRKB5Rv-8oJ5=-FVaSeFSUCC5C3HN2ZPjgZPS=jA@mail.gmail.com
Whole thread Raw
In response to Re: race condition in pg_class  (Noah Misch <noah@leadboat.com>)
Responses Re: race condition in pg_class
List pgsql-hackers
On Sun, May 12, 2024 at 7:29 PM Noah Misch <noah@leadboat.com> wrote:
> - [consequences limited to transient failure] Since a PROC_IN_VACUUM backend's
>   xmin does not stop pruning, an MVCC scan in that backend can find zero
>   tuples when one is live.  This is like what all backends got in the days of
>   SnapshotNow catalog scans.  See the pgbench test suite addition.  (Perhaps
>   the fix is to make VACUUM do its MVCC scans outside of PROC_IN_VACUUM,
>   setting that flag later and unsetting it earlier.)

Are you saying that this is a problem already, or that the patch
causes it to start happening? If it's the former, that's horrible. If
it's the latter, I'd say that is a fatal defect.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: WAL_LOG CREATE DATABASE strategy broken for non-standard page layouts
Next
From: Tom Lane
Date:
Subject: Re: Why is citext/regress failing on hamerkop?