notification information functions

I am working on moving the notification buffer into shared memory as
previously discussed. Since pg_listener will no longer exist, I think we
need to provide a couple of information functions.

I suggest:

pg_listened_events(out event name) returns setof record
pg_pending_events(out event name, out message text) returns setof record

The first would show events being listened on by the current backend,
while the second would show all pending events for the current db.

Given that there will no longer be any central place where events will
be registered to be listened on, it will not be possible to show all
such events for the current db.

Comments?

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I suggest:

> pg_listened_events(out event name) returns setof record
> pg_pending_events(out event name, out message text) returns setof record

> The first would show events being listened on by the current backend,
> while the second would show all pending events for the current db.

pg_listened_events seems reasonable, but what's a "pending event"?
If you mean stuff that hasn't yet been removed from the shared circular
buffer, it seems like that would be too transient (not to mention
implementation-dependent) to be interesting.

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> I suggest:
>>
>
>
>> pg_listened_events(out event name) returns setof record
>> pg_pending_events(out event name, out message text) returns setof record
>>
>
>
>> The first would show events being listened on by the current backend,
>> while the second would show all pending events for the current db.
>>
>
> pg_listened_events seems reasonable, but what's a "pending event"?
> If you mean stuff that hasn't yet been removed from the shared circular
> buffer, it seems like that would be too transient (not to mention
> implementation-dependent) to be interesting.
>
>
>

Fair enough. I'm all for less work ;-)

cheers

andrew

On Sun, 2008-05-18 at 16:00 -0400, Andrew Dunstan wrote:
> I am working on moving the notification buffer into shared memory as
> previously discussed. Since pg_listener will no longer exist, I think we
> need to provide a couple of information functions.
>
> I suggest:
>
> pg_listened_events(out event name) returns setof record
> pg_pending_events(out event name, out message text) returns setof record
>
> The first would show events being listened on by the current backend,
> while the second would show all pending events for the current db.
>
> Given that there will no longer be any central place where events will
> be registered to be listened on, it will not be possible to show all
> such events for the current db.

Are you sure that there will be no central place ?

How will we know then that all listeners have received their events ?

------------------
Hannu

Hannu Krosing wrote:
> On Sun, 2008-05-18 at 16:00 -0400, Andrew Dunstan wrote:
>
>> I am working on moving the notification buffer into shared memory as
>> previously discussed. Since pg_listener will no longer exist, I think we
>> need to provide a couple of information functions.
>>
>> I suggest:
>>
>> pg_listened_events(out event name) returns setof record
>> pg_pending_events(out event name, out message text) returns setof record
>>
>> The first would show events being listened on by the current backend,
>> while the second would show all pending events for the current db.
>>
>> Given that there will no longer be any central place where events will
>> be registered to be listened on, it will not be possible to show all
>> such events for the current db.
>>
>
> Are you sure that there will be no central place ?
>
> How will we know then that all listeners have received their events ?
>

Yes, quite sure. See Tom's answer to more or less this question from a
year ago:

http://archives.postgresql.org/pgsql-hackers/2007-03/msg01570.php

What we will have in shared memory is each backend's queue pointer (if any).

cheers

andrew

Hannu Krosing <hannu(at)krosing(dot)net> writes:
> How will we know then that all listeners have received their events ?

We won't, but we don't know that now. In both the current
implementation and this proposed one, the most you can tell is whether a
backend has absorbed an event notification, not whether it has passed it
on to its client. ISTM the timing of the first event is an
implementation artifact and not interesting for users.

regards, tom lane