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 →
-
Use a hash table to de-duplicate NOTIFY events faster.
- bb5ae8f6c416 13.0 landed