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.


Jan

> 
> 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.
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #