On Wed, 18 Nov 2009 22:12:18 -0500 Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> > (4) drop *old* notifications if the queue is full.
>
> > Since everyone has made the point that LISTEN is not meant to be a full
> > queueing system, I have no problem dropping notifications LRU-style.
>
> NO, NO, NO, a thousand times no!
>
> That turns NOTIFY into an unreliable signaling system, and if I haven't
> made this perfectly clear yet, any such change will be committed over my
> dead body.
>
> If we are unable to insert a new message into the queue, the correct
> recourse is to fail the transaction that is trying to insert the *new*
> message. Not to drop messages from already-committed transactions.
> Failing the current transaction still leaves things in a consistent
> state, ie, you don't get messages from aborted transactions but that's
> okay because they didn't change the database state.
+1
And in addition i don't like the idea of having the sender sitting
around until there's room for more messages in the queue, because some
very old backends didn't remove the stuff from the same.
So, yes, just failing the current transaction seems reasonable. We are
talking about millions of messages in the queue ...
Bye
-- Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
