From: | A(dot)M(dot) <agentm(at)themactionfaction(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Listen / Notify rewrite |
Date: | 2009-11-12 03:21:55 |
Message-ID: | 631F3E12-8672-46BF-91F4-E54DB236DE33@themactionfaction.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Nov 11, 2009, at 9:28 PM, Merlin Moncure wrote:
> On Wed, Nov 11, 2009 at 5:48 PM, A.M.
> <agentm(at)themactionfaction(dot)com> wrote:
>> At least with this new payload, I can set the payload to the
>> transaction ID
>> and be certain that all the notifications I sent are processed
>> (and in order
>> even!) but could you explain why the coalescing is still necessary?
>
> Christmas comes early this year! :-).
>
> three reasons:
> *) it works that way now...a lot of people use this feature for all
> kinds of subtle things and the behavior chould change as little as
> possible
> *) legacy issues aside, I think it's generally better behavior (how
> many times do you need to be tapped on the shoulder?)
> *) since you can trivially differentiate it (using xid, sequence,
> etc), what's the fuss?
Except for the fact that the number of times a notification occurred
may be valuable information.
I thought of a compromise: add the number of times a notification was
generated (coalesced count+1) to the callback data. That would
satisfy any backwards compatibility concerns and my use case too!
Cheers,
M
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-12 03:25:09 | Re: Listen / Notify rewrite |
Previous Message | Tom Lane | 2009-11-12 03:03:36 | Re: write ahead logging in standby (streaming replication) |