Thread: Another notify question

Recently I inquired about the notify command, and I was very pleased with the
response I recieved. I am glad the developers have decided to implement a
string argument in the future.

The discussion about implementation has lead me to the following question:
What should I be sure that notify will do? Tom seems to think that delivery
of a notification should not be guarenteed (if I understand what he is
saying), which is fine with me. However, I would like to know what the
specification of notify is so that I can adjust my application accordingly.
If I might not recieve a notification, or if I might recieve too many, I
would like to know.

Regards,
    Jeff

Jeff Davis <list-pgsql-general@dynworks.com> writes:
> The discussion about implementation has lead me to the following question:
> What should I be sure that notify will do? Tom seems to think that delivery
> of a notification should not be guarenteed (if I understand what he is
> saying), which is fine with me.

Well, I definitely wasn't advocating that.  IMHO you should be
guaranteed the delivery of *some* notification, but possibly one
containing less information than what was sent.  Or you might get
a notification when in fact none was sent.  This should be okay
for ordinary uses of NOTIFY, as long as such cases are infrequent
(so that you don't waste many cycles checking for events that
didn't happen).

            regards, tom lane

> Well, I definitely wasn't advocating that.  IMHO you should be
> guaranteed the delivery of *some* notification, but possibly one
> containing less information than what was sent.  Or you might get
> a notification when in fact none was sent.  This should be okay
> for ordinary uses of NOTIFY, as long as such cases are infrequent
> (so that you don't waste many cycles checking for events that
> didn't happen).
 Ok, that's good. Under what circumstances might I recieve less information?
I assume that the information might be truncated from the text argument, but
could you clarify?

Thanks,
    Jeff

On Mon, 2002-03-25 at 03:23, Jeff Davis wrote:
> > Well, I definitely wasn't advocating that.  IMHO you should be
> > guaranteed the delivery of *some* notification, but possibly one
> > containing less information than what was sent.  Or you might get
> > a notification when in fact none was sent.  This should be okay
> > for ordinary uses of NOTIFY, as long as such cases are infrequent
> > (so that you don't waste many cycles checking for events that
> > didn't happen).
>  Ok, that's good. Under what circumstances might I recieve less information?

When the notification buffer overruns. This will mostly likely occur
when a listening backend engages in a long-running transaction (since
the buffer is only checked when the listening backend finishes a
transaction). If you ensure that your listening backend doesn't engage
in long-running transactions (if necessary, just open another connection
to the DB), I wouldn't expect this to occur very often (or perhaps
ever). Of course, it's _possible_, so your application should be
prepared to handle it.

> I assume that the information might be truncated from the text argument, but
> could you clarify?

The message will be NULL and the backend PID will be set to a constant;
this will allow you to determine that an overrun has occurred so you can
take appropriate action.

See the discussion on -hackers for more details. Of course, all of this
is conditional on a new NOTIFY implementation, which I haven't
implemented yet -- but this is the expected behavior.

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC