Re: proposal: make NOTIFY list de-duplication optional
Vik Fearing <vik@2ndquadrant.fr>
From: Vik Fearing <vik@2ndquadrant.fr>
To: Filip Rembiałkowski <filip.rembialkowski@gmail.com>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2016-02-07T15:37:30Z
Lists: pgsql-hackers
On 02/07/2016 04:00 PM, Filip Rembiałkowski wrote:
> On Sun, Feb 7, 2016 at 11:54 AM, Vik Fearing <vik@2ndquadrant.fr> wrote:
>> I seem to remember some discussion about not using DEFAULT parameters in
>> system functions so you should leave the old function alone and create a
>> new function with your use_all parameter. I don't recall the exact
>> reason why so hopefully someone else will enlighten me.
>
> I'm quite new to this; how do I pinpoint proper OID for a new catalog
> object (function, in this case)?
> Is there a better way than browsing fmgr files and guessing next available oid?
There is a shell script called `unused_oids` in src/include/catalog/.
>> 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?
Compare with the behavior of:
select 1
union all
select 1
union distinct
select 1
union all
select 1;
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
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