Re: Another notify question
От | Neil Conway |
---|---|
Тема | Re: Another notify question |
Дата | |
Msg-id | 1017081916.2603.7.camel@jiro обсуждение исходный текст |
Ответ на | Re: Another notify question (Jeff Davis <list-pgsql-general@dynworks.com>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: