> On 7/29/2005 2:14 PM, Christopher Browne wrote:
>> Vivek Khera wrote:
>>
>>> On Jul 29, 2005, at 5:16 AM, Hannu Krosing wrote:
>>>
>>>> I'd actually like the choice of listen/notify or polling to be a
>>>> configuration decision made by administrator.
>>>>
>>>
>>> It is my experience that such settings are usually set incorrectly
>>> when left to the human...  I suppose the recommended setting would be
>>> "auto" so it could switch back and forth depending on load.
>>
>> Right.
>>
>> And it seems to me that the reason for a "dogmatic" position would be
>> that someone might prefer to "never use NOTIFY" because of some
>> perceived problem of the past, a perceived problem which a competent
>> policy should transform into an incorrect perception.
>>
>> The elimination of CONFIRM notifications should already cut pg_listener
>> traffic in half; a reasonable "switchover" policy should virtually
>> eliminate the traffic for heavily updated servers.
>
> Don't forget that WAIT FOR EVENT relies on CONFIRM's to come in. If your
> make their delivery random on "something happens anyway", you might end
> up waiting forever.

An excellent thought, but hopefully not correct ;-).

WAIT FOR EVENT does not rely on CONFIRM *events* taking place, but rather
on  remoteListen_forward_confirm(node, conn) being invoked "often enough."

If we fold Confirm and Event together, then both will be invoked equally
often, whether invoked via polling or via NOTIFY.

Forever is a pretty long time; as long as a default polling interval is
significantly less than the WAIT FOR EVENT timeout, methinks we're OK.

That definitely warrants care...