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.

If the automatic policy is being handled at all properly, there is
really only one reason to be consistently using NOTIFY calls, and that
reason is that  SYNCs are being generated very infrequently.  That
implies that replicated data is being updated infrequently, and that
there aren't many SYNCs being generated per hour, and that there aren't
many NOTIFY calls, ergo the historical pg_listener "problems" should not
be causing a problem.

I suppose it's not impossible for there to still be a problem; if
someone holds transactions open for days upon end, it is impossible to
clean out pg_listener.  But replication oughtn't suffer much, because
the fact that the system is using NOTIFY would imply that there aren't
many SYNCs, and so even if they run somewhat slowly, replication
shouldn't need to fall behind.

At any rate, if the policy handled at all appropriately, this should
"play well" on both busy and quiet clusters, so that rather than taking
the "Oracle model" of expecting omniscient DBAs, they ought normally to
not need to worry about this.