Re: proposal: make NOTIFY list de-duplication optional

On 8 February 2016 at 09:37, Filip Rembiałkowski <
filip.rembialkowski@gmail.com> wrote:

> On Sun, Feb 7, 2016 at 4:37 PM, Vik Fearing <vik@2ndquadrant.fr> wrote:
>
> >>> There is also no mention in the documentation about what happens if I
> do:
> >>>
> >>>     NOTIFY ALL chan, 'msg';
> >>>     NOTIFY ALL chan, 'msg';
> >>>     NOTIFY DISTINCT chan, 'msg';
> >>>     NOTIFY ALL chan, 'msg';
> >>>
> >>> Without testing, I'd say I'd get two messages, but it should be
> >>> explicitly mentioned somewhere.
> >>
> >> If it's four separate transactions, LISTEN'er should get four.
> >
> > The question was for one transaction, I should have been clearer about
> that.
> >
> >> If it's in one transaction,  LISTEN'er should get three.
> >
> > This is surprising to me, I would think it would get only two.  What is
> > your rationale for three?
> >
>
> It is a single transaction, but four separate commands.
>
> >>>     NOTIFY ALL chan, 'msg';
> -- send the message, save in the list/hash
> >>>     NOTIFY ALL chan, 'msg';
> -- ALL was specified, send the message even if it is on the list/hash
> >>>     NOTIFY DISTINCT chan, 'msg';
> -- default mode, skip message because it's in the list/hash
> >>>     NOTIFY ALL chan, 'msg';
> -- ALL was specified, send the message even if it is hashed/saved
>

So in total three messages are sent?

Would it be correct to say that if ALL is specified then a message is
queued no matter what. If DISTINCT is specified then it is only queued if
no message with the same channel and argument is already queued for
delivery. Using DISTINCT can never decrease the total number of messages to
be sent.

Right?

If so, I think that's the right behaviour and the docs just need to be
explicit - an example like the above would be good, translated to be
friendlier to those who don't know the internal mechanics.

I've found the deduplication functionality of NOTIFY very frustrating in
the past and I see this as a significant improvement. Sometimes the *number
of times* something happened is significant too...

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services