From: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Catalog for LISTEN'ed to notification channels? |
Date: | 2023-06-22 14:16:03 |
Message-ID: | CAFCRh-_dGU8-NDkRGyLnh-Zi=gWXVMx9pvWxr8=wNwBmzUBPyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Jun 22, 2023 at 3:30 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dominique Devienne <ddevienne(at)gmail(dot)com> writes:
> > Can I introspect which "channel(s)" the current (or any other session) is
> > LISTEN'ing to?
>
> The pg_listening_channels() function will show you channel names the
> current session is listening to. There's no way to find out about
> other sessions, because that state is only backend-local.
>
Thanks Tom. I'll take that. Useful for unit tests at least.
If anyone can share more info or pointers on the design and rationals for
async notification in PostgreSQL, why it is transactional only, with the
issue
that ensues, and whether there are any plans about it, I'd appreciate.
Thanks, --DD
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Mueller | 2023-06-22 15:05:52 | a really dumb password question |
Previous Message | Abhishek Dasgupta | 2023-06-22 13:46:21 | FIPS-related Error: Password Must Be at Least 112 Bits on Postgres 14, Unlike in Postgres 11 |