Re: Notify enhancement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Notify enhancement
Date
Msg-id 21349.1166214996@sss.pgh.pa.us
Whole thread Raw
In response to Re: Notify enhancement  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Notify enhancement  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
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).
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Operator class group proposal
Next
From: Andrew Dunstan
Date:
Subject: Re: Notify enhancement