Re: [PATCH] Fix LISTEN startup race with direct advancement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joel Jacobson" <joel(at)compiler(dot)org>
Cc: "Arseniy Mukhin" <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Fix LISTEN startup race with direct advancement
Date: 2026-05-26 15:40:09
Message-ID: 14717.1779810009@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Joel Jacobson" <joel(at)compiler(dot)org> writes:
> Ohh, right, thanks for spotting. New version attached, 0001 and 0002 identical,
> and 0003 now only contain the fix.

I agree with this fix, but it seems to me that it changes the meaning
of the ListenerEntry.listening flag in a rather fundamental way.
I'm tempted to rename that flag to "committed" or something like that.

(Both "listening" and "committed" appear in dozens of places in this
file that are not references to this flag, so TBH I'd rather use a
flag name that is not either of those words. But I can't think of
a better name.)

Also, while the proposed test cases are good for showing that there's
a bug here, I'm disinclined to commit them. I do not think there is
value in them proportionate to the cost of two new isolation-test
instances.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2026-05-26 15:46:12 Re: First draft of PG 19 release notes
Previous Message Euler Taveira 2026-05-26 15:39:01 Re: NULL pointer dereference in syslogger with load_libraries() and -DEXEC_BACKEND at startup