Re: Optimize LISTEN/NOTIFY - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: Optimize LISTEN/NOTIFY
Date
Msg-id fd2df1f6-79e3-48e2-9284-e105a7719ac0@app.fastmail.com
Whole thread Raw
In response to Re: Optimize LISTEN/NOTIFY  ("Joel Jacobson" <joel@compiler.org>)
Responses Re: Optimize LISTEN/NOTIFY
List 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

pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Logical Replication of sequences
Next
From: Tom Lane
Date:
Subject: Re: Optimize LISTEN/NOTIFY