Re: proposal: make NOTIFY list de-duplication optional

Filip Rembiałkowski <filip.rembialkowski@gmail.com>

From: Filip Rembiałkowski <filip.rembialkowski@gmail.com>
To: Vik Fearing <vik@2ndquadrant.fr>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2016-02-08T01:37:39Z
Lists: pgsql-hackers
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


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Use a hash table to de-duplicate NOTIFY events faster.