From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Notify enhancement |
Date: | 2006-12-15 20:36:36 |
Message-ID: | 21349.1166214996@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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).
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-12-15 20:59:20 | Re: Notify enhancement |
Previous Message | Tom Lane | 2006-12-15 19:38:56 | Re: Operator class group proposal |