Re: Listen / Notify rewrite
От | A.M. |
---|---|
Тема | Re: Listen / Notify rewrite |
Дата | |
Msg-id | 631F3E12-8672-46BF-91F4-E54DB236DE33@themactionfaction.com обсуждение исходный текст |
Ответ на | Re: Listen / Notify rewrite (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: Listen / Notify rewrite
|
Список | 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@themactionfaction.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
В списке pgsql-hackers по дате отправления: