Re: SimpleLruTruncate() mutual exclusion

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.GC32531@gust.leadboat.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/.