On Sat, Oct 08, 2005 at 04:59:22PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> > Maybe I'm missing something, but is it possible to ensure notifications
> > aren't lost using Heikki's method, since everything's only in shared
> > memory? Or is the idea that stuff would not survive a backend crash?
>
> Listen/notify state has never survived a crash (since it is defined in
> terms of PIDs that will no longer exist after a DB restart), and I don't
> really see any reason why we'd want it to. An application reconnecting
> after a DB crash would have to assume it might have missed some
> notifications occurring before it could reconnect, and would have to
> re-determine what the database state is anyway.
>
> But I think you might be confusing that with the feature-or-bug
> (depending on one's point of view) that duplicate notifications can be
> merged into one event. I'm inclined to preserve that behavior,
> primarily because not doing so would create a tremendous penalty on
> applications that expect it to work that way. With addition of payload
> data it'd be easy for apps that don't want merging to prevent it: just
> add an otherwise-uninteresting serial number to the payload string.
> We'd certainly want to define the "duplicate" test to consider the
> payload string as well as the topic name.
I thought the idea behind NOTIFY 'msg' was to enable some form of
queuing, or at least something that ensures the notification sticks
around until picked up. I see I was wrong. :)
Before ripping out the old code, would it be useful as the basis for a
queue/notification system that ensures a message sticks around until at
least one listener picks it up? Granted, I think such a thing could be
built using the new notification system along with a table, but if the
code's already there and useful...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461