Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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.



---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to