On Sat, Oct 08, 2005 at 04:59:22PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
