From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Jeff Davis <jdavis-pgsql(at)empires(dot)org> |
Cc: | Slony-I Mailing List <slony1-general(at)gborg(dot)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Slony-I goes BETA (possible bug) |
Date: | 2004-06-07 13:20:00 |
Message-ID: | 40C46B80.7090004@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-general pgsql-hackers |
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(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2004-06-07 18:33:58 | Re: [HACKERS] Slony-I goes BETA (possible bug) |
Previous Message | Thomas Hallgren | 2004-06-07 06:20:35 | Re: [HACKERS] Not 7.5, but 8.0 ? |
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2004-06-07 13:56:56 | Re: Backup and Restore of PostgreSQL |
Previous Message | Tim Penhey | 2004-06-07 13:14:47 | Re: Backup and Restore of PostgreSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-06-07 13:26:12 | Re: Failures with windows port |
Previous Message | Andreas Pflug | 2004-06-07 11:03:15 | Re: serverlog function (log_destination file) |