Re: Another notify question

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