On Mon, Nov 16, 2009 at 2:35 PM, Andrew Chernow <a...@esilo.com> wrote: > >>> 1) drop new notifications if the queue is full (silently or with >>> rollback) >> >> I like this one best, but not with silence of course. While it's not the >> most >> polite thing to do, this is for a super extreme edge case. I'd rather just >> throw an exception if the queue is full rather than start messing with the > > +1
So if you guys are going to insist on turning the notification mechanism isn't a queueing mechanism I think it at least behooves you to have it degrade gracefully into a notification mechanism and not become entirely useless by dropping notification messages. That is, if the queue overflows what you should do is drop the payloads and condense all the messages for a given class into a single notification for that class with "unknown payload". That way if a cache which wants to invalidate specific objects gets a queue overflow condition then at least it knows it should rescan the original data and rebuild the cache and not just serve invalid data. I still think you're on the wrong path entirely and will end up with a mechanism which serves neither use case very well instead of two separate mechanisms that are properly designed for the two use cases. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
