Re: [HACKERS] Slony-I goes BETA (possible bug) - Mailing list pgsql-advocacy

From Jan Wieck
Subject Re: [HACKERS] Slony-I goes BETA (possible bug)
Date
Msg-id 40C46B80.7090004@Yahoo.com
Whole thread Raw
In response to Re: [HACKERS] Slony-I goes BETA (possible bug)  (Jeff Davis <jdavis-pgsql@empires.org>)
Responses Re: [HACKERS] Slony-I goes BETA (possible bug)
List pgsql-advocacy
I tend to agree with you that spurious SYNC's aren't the end of the
world. The idea of using notify to tell the syncThread somthing happened
is probably the right way to do it, but at this time a little invasive.
We need more time to investigate how to avoid notice storms during high
update activity on the master.


Jan


On 6/6/2004 2:33 PM, Jeff Davis wrote:

> On Sun, 2004-06-06 at 10:32, Jan Wieck wrote:
>> You are right. The "local" slon node checks every "-s" milliseconds
>> (commandline switch) if the sequence sl_action_seq has changed, and if
>> so generate a SYNC event. Bumping a sequence alone does not cause this,
>> only operations that invoke the log trigger on replicated tables do.
>>
>> Speaking of this, this would also mean that there is a gap between the
>> last sl_action_seq bumping operation and the commit of that transaction.
>> If the local slon will generate the sync right in that gap, the changes
>> done in that transaction will not be replicated until the next
>> transaction triggers another sync.
>>
>> I am not sure how to effectively avoid this problem without blindly
>> creating SYNC events in a maybe less frequent interval. Suggestions?
>
>
> A couple thoughts occur to me:
>
> Spurious SYNCs might not be the end of the world, because if someone is
> using replication, they probably don't mind the unneeded costs of a SYNC
> when the database is not being used heavily. If it is being used
> heavily, the SYNCs will have to happen anyway.
>
> Also, it might be possibly to make use of NOTIFY somehow, because
> notifications only occur after a transaction commits. Perhaps you can
> issue a notify for each transaction that modifies a replicated table and
> slon could listen for that notification? That way, it wouldn't SYNC
> before the transaction commits and miss the uncommitted data.
>
> Regards,
>     Jeff Davis


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


pgsql-advocacy by date:

Previous
From: "Thomas Hallgren"
Date:
Subject: Re: [HACKERS] Not 7.5, but 8.0 ?
Next
From: Jeff Davis
Date:
Subject: Re: [HACKERS] Slony-I goes BETA (possible bug)