Content-Type: multipart/alternative;
 boundary="------------CgADW9RotB1r3uN8qRNKeLlq"
Message-ID: <037ce9cd-28ad-4c19-9be1-d8c1f577a322@gmail.com>
Date: Sun, 19 Apr 2026 07:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Optimize LISTEN/NOTIFY
To: Tom Lane <tgl@sss.pgh.pa.us>, Joel Jacobson <joel@compiler.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
References: <6899c044-4a82-49be-8117-e6f669765f7e@app.fastmail.com>
 <2531672.1759868124@sss.pgh.pa.us>
 <474efa78-337c-41cd-a73a-f845a0115109@app.fastmail.com>
 <2749343.1759949176@sss.pgh.pa.us>
 <8bfca2be-1ec0-4e15-aafb-0b7b661fe936@app.fastmail.com>
 <9eba307f-f2fb-48f0-9507-2e197f39ef9e@app.fastmail.com>
 <cde2a91d-d47a-43b5-ab27-f98aa739d38e@app.fastmail.com>
 <8c71183a-0d28-4bcf-a806-78446ff95404@app.fastmail.com>
 <1009807.1760476747@sss.pgh.pa.us>
 <1F7227F5-C33D-4E2C-8511-33F1468590D0@gmail.com>
 <0a5a20d3-4621-46b3-b2ab-903f63a20dea@app.fastmail.com>
 <6F913129-ABEF-4004-AAF3! -F! !22!F!C!3!4!29AE8@gmail.com>
 <cbabbb45-ec27-47f1-a8f3-eb29073e9aef@app.fastmail.com>
 <ceab2c54-3463-4029-a7d8-895a617bb457@app.fastmail.com>
 <1547585.1760645808@sss.pgh.pa.us>
 <b8df8040-1b15-4a1a-b5f6-74acebbd2d0c@app.fastmail.com>
 <CAE7r3MLivh1sHWF06hrVXkiQbw-KChPcQsh+9CheXprm5vRVMQ@mail.gmail.com>
 <14865EB6-0BF4-462B-9 <803584.1768503335@sss.pgh.pa.us>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <803584.1768503335@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/037ce9cd-28ad-4c19-9be1-d8c1f577a322%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------CgADW9RotB1r3uN8qRNKeLlq
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Tom and Joel,

15.01.2026 20:55, Tom Lane wrote:
> Anyway, at this point I'm content to go ahead with v35, and
> I'll push that in a little bit.  Perhaps we should take a TODO
> to figure out why this test scenario runs so poorly on macOS;
> but I'll bet that the answer is not anywhere near async.c itself.

While browsing through new inconsistencies and typos, I came across one
which I'm not sure what to do with. Could you help, please?

async-notify.spec contains:
# Check ChannelHashAddListener array growth.
permutation listenc llisten l2listen l3listen lslisten

But as far as I can see, ChannelHashAddListener() was eliminated in
0002-optimize_listen_notify-v13.patch upthread [1]:

> > Or thinking a little bigger: why are we maintaining the set of
> > channels-listened-to both as a list and a hash? Could we remove
> > the list form?
>
> Yes, it was indeed possible to remove the list form.
>

So, maybe the comment or perhaps even the test case should be changed/
removed?

[1] https://www.postgresql.org/message-id/8bfca2be-1ec0-4e15-aafb-0b7b661fe936%40app.fastmail.com

Best regards,
Alexander
--------------CgADW9RotB1r3uN8qRNKeLlq
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Tom and Joel,<br>
      <br>
      15.01.2026 20:55, Tom Lane wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:803584.1768503335@sss.pgh.pa.us">
      <pre wrap="" class="moz-quote-pre">Anyway, at this point I'm content to go ahead with v35, and
I'll push that in a little bit.  Perhaps we should take a TODO
to figure out why this test scenario runs so poorly on macOS;
but I'll bet that the answer is not anywhere near async.c itself.
</pre>
    </blockquote>
    <br>
    While browsing through new inconsistencies and typos, I came across
    one<br>
    which I'm not sure what to do with. Could you help, please?<br>
    <br>
    async-notify.spec contains:<br>
    # Check ChannelHashAddListener array growth.<br>
    permutation listenc llisten l2listen l3listen lslisten<br>
    <br>
    But as far as I can see, ChannelHashAddListener() was eliminated in<br>
    0002-optimize_listen_notify-v13.patch upthread [1]:<br>
    <br>
    <blockquote type="cite">&gt; Or thinking a little bigger: why are we
      maintaining the set of<br>
      &gt; channels-listened-to both as a list and a hash? Could we
      remove<br>
      &gt; the list form?
      <p>Yes, it was indeed possible to remove the list form.</p>
    </blockquote>
    <br>
    So, maybe the comment or perhaps even the test case should be
    changed/<br>
    removed?<br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="https://www.postgresql.org/message-id/8bfca2be-1ec0-4e15-aafb-0b7b661fe936%40app.fastmail.com">https://www.postgresql.org/message-id/8bfca2be-1ec0-4e15-aafb-0b7b661fe936%40app.fastmail.com</a><br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------CgADW9RotB1r3uN8qRNKeLlq--