Re: notification payloads

Tom Lane wrote:
> Hannu Krosing <hannu@skype.net> writes:
>   
>> Ühel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan:
>>     
>>> Er, what listen table? 
>>>       
>
>   
>> At least the list of which backends listen to which events should be
>> also in shared mem.
>>     
>
> No, the intent is specifically that there will be *no* such global
> structure.  All it does is add complexity, not to mention make it
> harder to size shared memory.
>
>   
>> How else would we know how many copies to make for each backend or when
>> we can release the memory in case we make one copy ?
>>     
>
> The proposed design is essentially a clone of the sinval messaging
> system, which does not need to know either of those and does not make
> "one copy per backend".  There's one copy, period.
>
>
>   

Further design notes:

What we will need to keep track of (a la sinval) is a queue pointer per 
backend. I think we can add an optimization to that by keeping a count 
of events listened to per backend, so that we only wake up active 
listeners. For non listeners we can just catch them up without bothering 
to wake them. This will help to avoid the potential for a "thundering 
herd" effect that has apparently bothered some people.

We'll also need to store the database id along with the event name and 
message, since pg_listener is per db rather than per cluster.

cheers

andrew