Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> My current (possibly naive) thought is that I'll need two structures,
>> one of <pid, event> listeners and one of <pid, event, message>
>> notifications waiting to be picked up, each protected by a lock. In the
>> case of the second structure, we would just separate the event and the
>> message by a null byte. Does that seem reasonable?
>>
>
> No. I think you should do it like sinval: the message ring carries
> *all* messages and it's up to the readers to take or discard individual
> messages. A backend would read the buffer at reasonable intervals and
> cache the messages it was interested in locally, for delivery to the
> client after the next transaction end (similar to current semantics).
>
Are we keeping use of SIGUSR2 in this scheme?
> This way, the information about who is listening to what doesn't need to
> be in shared memory, and there's only one configuration parameter, the
> message ring buffer size, which the DBA can size based on estimates of
> message traffic rate.
>
I don't understand how we decide that everybody who needs a given
event+message has got it, if we don't know who (if anyone) is listening?
How do we decide that we no longer need the info in the shmem buffer?
Timeout? sinval issues a reset if the buffer becomes full, but we can't
do that here.
I assume you don't intend that we keep one copy per backend regardless
of whether or not it is listening.
I'm feeling a little dense here ... there must be something I'm not getting.
cheers
andrew