Simon Riggs <simon@2ndQuadrant.com> writes:
> On Sun, 2009-11-15 at 16:48 -0500, Tom Lane wrote:
>> You misunderstand the requirements. LISTEN notifications are *not*
>> meant to survive a database crash, and never have been. However,
>> so long as both client and server stay up, they must be reliable.
>> If the client has to poll database state because it might have
>> missed a notification, the feature is just a waste of time.
> Why would it be so important for messages to be reliable if the database
> is up, yet its OK to lose messages if it crashes? The application must
> still allow for the case that messages are lost.
No, that's the point. The design center for LISTEN is that you have a
client that needs to respond to changes in the DB state. When it first
connects it will issue LISTEN and then (order is important) it will
examine the current state of the database. After that it can just wait
for NOTIFY to tell it that something interesting has happened. If it
crashes, or sees a disconnect indicating that the server has crashed,
it goes back to the startup point. No problem. But if it can't be sure
that it will get a NOTIFY every time something happens to the DB state,
then it has to do active polling of the state instead, and the NOTIFY
feature is really worthless to it.
This is an entirely useful and reliable feature within these parameters
--- the first application I ever wrote using PG relied on NOTIFY to work
this way. (In fact it wouldn't be overstating the case to say that
I wouldn't be a PG hacker today if it weren't for LISTEN/NOTIFY.)
regards, tom lane