On Fri, Jun 28, 2019 at 10:06:28AM -0700, Noah Misch wrote:
> On Sun, Feb 17, 2019 at 11:31:03PM -0800, Noah Misch wrote:
> > I'm forking this thread from
> > https://postgr.es/m/flat/20190202083822(dot)GC32531(at)gust(dot)leadboat(dot)com, which
> > reported a race condition involving the "apparent wraparound" safety check in
> > SimpleLruTruncate():
> >
> > On Wed, Feb 13, 2019 at 11:26:23PM -0800, Noah Misch wrote:
> > > 1. The result of the test is valid only until we release the SLRU ControlLock,
> > > which we do before SlruScanDirCbDeleteCutoff() uses the cutoff to evaluate
> > > segments for deletion. Once we release that lock, latest_page_number can
> > > advance. This creates a TOCTOU race condition, allowing excess deletion:
> > >
> > > [local] test=# table trunc_clog_concurrency ;
> > > ERROR: could not access status of transaction 2149484247
> > > DETAIL: Could not open file "pg_xact/0801": No such file or directory.
> >
> > > Fixes are available:
> >
> > > b. Arrange so only one backend runs vac_truncate_clog() at a time. Other than
> > > AsyncCtl, every SLRU truncation appears in vac_truncate_clog(), in a
> > > checkpoint, or in the startup process. Hence, also arrange for only one
> > > backend to call SimpleLruTruncate(AsyncCtl) at a time.
> >
> > More specifically, restrict vac_update_datfrozenxid() to one backend per
> > database, and restrict vac_truncate_clog() and asyncQueueAdvanceTail() to one
> > backend per cluster. This, attached, was rather straightforward.
>
> Rebased. The conflicts were limited to comments and documentation.
Rebased, most notably over the lock renames of commit 5da1493. In
LockTagTypeNames, I did s/frozen IDs/frozenid/ for consistency with that
commit having done s/speculative token/spectoken/.