Re: Add pattern matching support for LISTEN/NOTIFY channels

On Mon Jun 8, 2026 at 7:16 PM -03, Tom Lane wrote:
> "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> writes:
>> I'd like to propose for PG 20 adding glob-style pattern matching support
>> for LISTEN channel names, allowing clients to subscribe to multiple
>> channels with a single LISTEN command using wildcards.
>
> I'm fairly skeptical that this is worth supporting at the server-code
> level. You can already accomplish equivalent things by listening on
> a single shared channel and pattern-matching against identifiers
> provided in the message payloads. Yes, doing that in C would reduce
> the cost of skipping uninteresting messages, but is that enough of a
> gain to justify adding this to our support workload?
>

Fair point. I think that the main appeal is reducing the need to
maintain dynamic LISTEN lists. For example, a multi-tenant app using
different schemas may want to monitor all tenants and could LISTEN
"tenant_*" instead of issuing separate LISTEN commands as tenants are
created and deleted. Similarly, an app using hierarchical channel names
like orders_created, orders_updated, orders_shipped could have a
reporting service LISTEN "orders_*" rather than explicitly listing each
event type. These are some use cases that I've already miss in the past.

That said, I'm also attracted to the idea of filtering on payload
content, which could achieve the same goal. I'd be interested in
thoughts on whether payload filtering would be a better direction.

> The proposed implementation doesn't seem that attractive anyway, since
> it gives up all the benefit of the targeted wakeups introduced in v19.
> If you consider a workload with some high-volume channels that are not
> interesting to the wild-card-using listener, it's not hard to believe
> that this is a net loss compared to the already-usable way.
>

The new attached patch aims to preserves targeted wakeups. Patterns are
stored in two shared memory structures: the globalChannelTable (keyed by
the pattern string itself, storing the listener list just like exact
channels) and a globalPatterns list (an enumerable array of all
registered patterns). When SignalBackends() processes a notification, it
first does an exact match lookup, then iterates globalPatterns testing
each pattern against the notification channel. For matching patterns, it
looks up listeners in globalChannelTable using the pattern as key and
wakes only those backends. A backend listening on "orders_*" won't be
woken for notifications to "user_123".

Of course we may have performance issues if the listen of patterns is
too big, but we may try to apply some optimizations and may try to use
another data structure instead of a list, but I think that the idea
would remain the same.

I've added comments throughout the code explaining the architecture,
particularly in the file header, around GlobalPatternList,
PrepareTableEntriesForListen, and SignalBackends. There are still some
XXX comments marking areas that need more thought, but I believe the
overall architecture remains the same. I'm mainly looking for feedback
on whether this approach makes sense before polishing the remaining
details.

FWIW I'm also studying the previous proposals, still thinking about the
issues already discussed on these.

Thanks.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com