Re: SV: Problem with pg_notify / listen

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Noah Misch <noah@leadboat.com>

Cc: Gustavsson Mikael <mikael.gustavsson@smhi.se>, pgsql-bugs@lists.postgresql.org, Svensson Peter <peter.svensson@smhi.se>, Almen Anders <anders.almen@smhi.se>

Date: 2020-11-28T04:03:40Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix a recently-introduced race condition in LISTEN/NOTIFY handling.
- f6324bbbe63c 10.16 landed
- f5de090cc175 13.2 landed
- cbc7a7a10c2d 12.6 landed
- 9c83b54a9ccd 14.0 landed
- 8a4069766079 9.6.21 landed
- 60d6c71430f9 9.5.25 landed
- 40f2fbe71ad6 11.11 landed
Prevent concurrent SimpleLruTruncate() for any given SLRU.
- d4031d78460c 11.10 cited

Noah Misch <noah@leadboat.com> writes:
> ... agreed.  In general, recycling SLRU space entails three steps that shall
> not overlap:

> 1. Stop reading data in the space, regulated by some "logical tail".
> 2. Unlink files wholly within the bounds of the space.
> 3. Start writing data into the space, regulated by some "physical tail" (most
>    often called a "stop limit").

Check.

> Commit d4031d7 fixed overlap of (2) and (3).  For pg_notify, though, it
> introduced overlap of (1) and (2).  I've now checked the other SLRUs for
> similar problems, but I found nothing urgent:

Good, I was wondering if we had any similar issues elsewhere.

> I think we don't yet have the right name here, seeing QUEUE_TAIL_PAGE !=
> QUEUE_POS_PAGE(QUEUE_TAIL) sounds paradoxical, yet happens regularly.  How
> about naming it QUEUE_STOP_PAGE?

Hmm, it's not very clear what "stop" means here.  What do you think of
QUEUE_OLDEST_PAGE?

			regards, tom lane