Re: SimpleLruTruncate() mutual exclusion

Dmitry Dolgov <9erthalion6@gmail.com>

From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2020-01-30T15:34:33Z
Lists: pgsql-hackers
> On Sun, Nov 17, 2019 at 10:14:26PM -0800, Noah Misch wrote:
>
> > I'm probably missing something, so just wanted to clarify. Do I
> > understand correctly, that thread [1] and this one are independent, and
> > it is assumed in the scenario above that we're at the end of XID space,
> > but not necessarily having rounding issues? I'm a bit confused, since
> > the reproduce script does something about cutoffPage, and I'm not sure
> > if it's important or not.
>
> I think the repro recipe contained an early fix for the other thread's bug.
> While they're independent in principle, I likely never reproduced this bug
> without having a fix in place for the other thread's bug.  The bug in the
> other thread was easier to hit.

Just to clarify, since the CF item for this patch was withdrawn
recently. Does it mean that eventually the thread [1] covers this one
too?

[1]: https://www.postgresql.org/message-id/flat/20190202083822.GC32531%40gust.leadboat.com



Commits

  1. Prevent concurrent SimpleLruTruncate() for any given SLRU.

  2. Rename SLRU structures and associated LWLocks.

  3. Improve ANALYZE's handling of concurrent-update scenarios.

  4. Avoid consuming an XID during vac_truncate_clog().