Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Slony-I goes BETA (possible bug)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacypgsql-generalpgsql-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.


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 #

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2004-06-07 13:26:12
Subject: Re: Failures with windows port
Previous:From: Andreas PflugDate: 2004-06-07 11:03:15
Subject: Re: serverlog function (log_destination file)

pgsql-advocacy by date

Next:From: Jeff DavisDate: 2004-06-07 18:33:58
Subject: Re: [HACKERS] Slony-I goes BETA (possible bug)
Previous:From: Thomas HallgrenDate: 2004-06-07 06:20:35
Subject: Re: [HACKERS] Not 7.5, but 8.0 ?

pgsql-general by date

Next:From: Richard HuxtonDate: 2004-06-07 13:56:56
Subject: Re: Backup and Restore of PostgreSQL
Previous:From: Tim PenheyDate: 2004-06-07 13:14:47
Subject: Re: Backup and Restore of PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group