From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimize LISTEN/NOTIFY |
Date: | 2025-10-07 05:39:08 |
Message-ID: | fd2df1f6-79e3-48e2-9284-e105a7719ac0@app.fastmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 6, 2025, at 22:22, Joel Jacobson wrote:
> On Mon, Oct 6, 2025, at 22:11, Joel Jacobson wrote:
>> The patch is now using dshash. I've been looking at code in launcher.c
>> when implementing it. The function init_channel_hash() ended up being
>> very similar to launcher.c's logicalrep_launcher_attach_dshmem().
>
> Noticed a mistake on one line just after pressing send.
> Sorry about that, new version attached.
Trying to fix the NetBSD failure.
I don't understand why 001_constraint_validation, test 'list_parted2_def
scanned' and test 'part_5 verified by existing constraints' should be
affected by this patch. I guess I could have gotten something wrong with
the locking with dshash, that might somehow affect other tests?
I've changed the dshash_find() in SignalBackends from dshash_find(...,
false) to dshash_find(..., true), that is, to take an exclusive lock
instead. Not sure if this is necessary, since we're not modifying the
entry, but we're already holding an exclusive lock on NotifyQueueLock
here, so I don't think it should affect concurrency.
Any help on looking specifically at the dshash code would be much
appreciated, since I'm new to this interface.
/Joel
Attachment | Content-Type | Size |
---|---|---|
optimize_listen_notify-v9.patch | application/octet-stream | 22.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-10-07 05:43:16 | Re: Optimize LISTEN/NOTIFY |
Previous Message | shveta malik | 2025-10-07 05:23:14 | Re: Logical Replication of sequences |