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