On 10/12/2004 10:35 AM, hannu at skype.net wrote:

>> Hi again ;)
>>
>> now I've got the following situation
>>
>> I did some subscription changes (slony 1.0.2, pg 7.4.5) and now I have
>> nodes 1 and 5 both subscribing to master node 2
>>
>> the replication is happening, but both 1 and 5 ended up with subscription
>> option forward = yes
>>
>> userdb=# select * from _userdb_cluster.sl_subscribe ;
>>  sub_set | sub_provider | sub_receiver | sub_forward | sub_active
>> ---------+--------------+--------------+-------------+------------
>>        1 |            2 |            5 | t           | t
>>        1 |            2 |            1 | t           | t
>> (2 rows)
>>
>> resulting in sl_log_1 with ~3M rows
> 
> Ok Now I was at leas able to convince slony to drop node5 , but I still have
> sl_log_1 file of 3.3M rows.
> 
> This manifests itself as periods of tens of seconds when the system halts
> to a crawl as slony vacuums that big table and clients timeout. The
> selects form sl_log_1 are slow as well, but at least they do not affect
> other operations ;(
> 
> My current solution is to stop slony on slaves during peak periods, but
> what I really would like is that the sl_log_1 could be trimmed down.

We have to work on log switching ... yes.


Jan

> 
> Other than this the replica is running fine.
> 
> ------------
> Hannu
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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 #