FYI,

I did the pg_dump/load another time and used repair config on this node. 
Now the provider is stuck on RESET CONFIG :

2009-08-11 16:54:01 CEST DEBUG1 main: running scheduler mainloop
2009-08-11 16:54:01 CEST DEBUG1 remoteListenThread_104: connected to 
'host=slave-db02.profiles.qualif.pns.b3.p.fti.net 
dbname=pns_voila_preprod user=pns_slon
y_voila_preprod port=5432 password=pns_v0!la_sl0ny_pr3pr0d'
2009-08-11 16:54:01 CEST DEBUG1 remoteListenThread_103: connected to 
'host=master-db02.profiles.qualif.pns.b3.p.fti.net 
dbname=pns_voila_preprod user=pns_slo
ny_voila_preprod port=5432 password=pns_v0!la_sl0ny_pr3pr0d'
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_103: queue event 
103,477 SYNC
2009-08-11 16:54:01 CEST DEBUG2 remoteWorkerThread_103: Received event 
103,477 SYNC
2009-08-11 16:54:01 CEST DEBUG2 remoteWorkerThread_103: SYNC 477 processing
2009-08-11 16:54:01 CEST DEBUG2 remoteWorkerThread_103: no sets need 
syncing for this event
2009-08-11 16:54:01 CEST DEBUG2 remoteWorkerThread_103: forward confirm 
101,113409 received by 104
2009-08-11 16:54:01 CEST DEBUG2 remoteWorkerThread_103: forward confirm 
101,112143 received by 102
2009-08-11 16:54:01 CEST DEBUG2 remoteWorkerThread_103: forward confirm 
101,114448 received by 103
2009-08-11 16:54:01 CEST DEBUG2 remoteWorkerThread_103: forward confirm 
103,207 received by 104
2009-08-11 16:54:01 CEST DEBUG2 remoteWorkerThread_103: forward confirm 
104,58 received by 103
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
103,477 SYNC
2009-08-11 16:54:01 CEST DEBUG2 remoteWorker_event: event 103,477 
ignored - duplicate
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,59 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,60 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteWorkerThread_104: Received event 
104,59 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,61 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,62 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,63 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,64 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,65 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,66 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,67 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,68 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,69 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,70 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,71 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,72 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,73 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,74 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,75 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,76 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,77 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,78 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,79 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,80 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,81 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 remoteListenThread_104: queue event 
104,82 RESET_CONFIG
2009-08-11 16:54:01 CEST DEBUG2 slon: child terminated status: 11; pid: 
24444, current worker pid: 24444
2009-08-11 16:54:01 CEST DEBUG1 slon: restart of worker in 10 seconds

and I really don't know what's happening ! other nodes are waiting for 
sync of set (that are updated) :

2009-08-11 16:54:49 CEST DEBUG2 calc sync size - last time: 1 last 
length: 6217 ideal: 3 proposed size: 3
2009-08-11 16:54:49 CEST DEBUG2 remoteWorkerThread_103: SYNC 482 processing
2009-08-11 16:54:49 CEST DEBUG2 remoteWorkerThread_103: no sets need 
syncing for this event
2009-08-11 16:54:49 CEST DEBUG2 syncThread: new sl_action_seq 1 - SYNC 223
2009-08-11 16:54:51 CEST DEBUG2 localListenThread: Received event 
104,223 SYNC
2009-08-11 16:54:54 CEST DEBUG2 remoteListenThread_101: LISTEN
2009-08-11 16:54:54 CEST DEBUG2 remoteWorkerThread_101: forward confirm 
103,482 received by 101
2009-08-11 16:54:59 CEST DEBUG2 syncThread: new sl_action_seq 1 - SYNC 224
2009-08-11 16:55:00 CEST DEBUG2 remoteListenThread_103: queue event 
103,483 SYNC
2009-08-11 16:55:00 CEST DEBUG2 remoteListenThread_103: UNLISTEN
2009-08-11 16:55:00 CEST DEBUG2 remoteWorkerThread_103: Received event 
103,483 SYNC
2009-08-11 16:55:00 CEST DEBUG2 calc sync size - last time: 1 last 
length: 11011 ideal: 1 proposed size: 1
2009-08-11 16:55:00 CEST DEBUG2 remoteWorkerThread_103: SYNC 483 processing
2009-08-11 16:55:00 CEST DEBUG2 remoteWorkerThread_103: no sets need 
syncing for this event
2009-08-11 16:55:01 CEST DEBUG2 localListenThread: Received event 
104,224 SYNC
2009-08-11 16:55:03 CEST DEBUG2 remoteWorkerThread_101: forward confirm 
103,483 received by 101
2009-08-11 16:55:04 CEST DEBUG2 remoteListenThread_103: LISTEN
2009-08-11 16:55:09 CEST DEBUG2 remoteListenThread_103: queue event 
103,484 SYNC
2009-08-11 16:55:09 CEST DEBUG2 remoteListenThread_103: UNLISTEN
2009-08-11 16:55:09 CEST DEBUG2 remoteWorkerThread_103: Received event 
103,484 SYNC
2009-08-11 16:55:09 CEST DEBUG2 calc sync size - last time: 1 last 
length: 8989 ideal: 2 proposed size: 2
2009-08-11 16:55:09 CEST DEBUG2 remoteWorkerThread_103: SYNC 484 processing
2009-08-11 16:55:09 CEST DEBUG2 remoteWorkerThread_103: no sets need 
syncing for this event
2009-08-11 16:55:09 CEST DEBUG2 syncThread: new sl_action_seq 1 - SYNC 225
2009-08-11 16:55:11 CEST DEBUG2 localListenThread: Received event 
104,225 SYNC
2009-08-11 16:55:13 CEST DEBUG2 remoteListenThread_103: LISTEN
2009-08-11 16:55:13 CEST DEBUG2 remoteWorkerThread_101: forward confirm 
103,484 received by 101
2009-08-11 16:55:19 CEST DEBUG2 remoteListenThread_103: queue event 
103,485 SYNC
2009-08-11 16:55:19 CEST DEBUG2 remoteListenThread_103: UNLISTEN
2009-08-11 16:55:19 CEST DEBUG2 remoteWorkerThread_103: Received event 
103,485 SYNC
2009-08-11 16:55:19 CEST DEBUG2 calc sync size - last time: 1 last 
length: 10003 ideal: 1 proposed size: 1
2009-08-11 16:55:19 CEST DEBUG2 remoteWorkerThread_103: SYNC 485 processing
2009-08-11 16:55:19 CEST DEBUG2 remoteWorkerThread_103: no sets need 
syncing for this event
2009-08-11 16:55:19 CEST DEBUG2 syncThread: new sl_action_seq 1 - SYNC 226
2009-08-11 16:55:21 CEST DEBUG2 localListenThread: Received event 
104,226 SYNC
2009-08-11 16:55:23 CEST DEBUG2 remoteListenThread_101: LISTEN
2009-08-11 16:55:24 CEST DEBUG2 remoteWorkerThread_101: forward confirm 
103,485 received by 101

any help ?

Should I really use update function on the node upgraded ? on every node ?

Cyril Scetbon a écrit :
> I had to submit it to the same node it was applied on. Still getting 
> some error and investiguating...
>
> Glyn Astill a écrit :
>> I'm not sure why repair config isn't working for you, however if 
>> you're looking for the baremetal function it is updatereloid(set, node).
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>  
>>> From: Cyril Scetbon <cscetbon.ext at orange-ftgroup.com>
>>> To: chris <chris at ca.afilias.info>; slony1-general at lists.slony.info
>>> Sent: Tuesday, 11 August, 2009 10:48:18
>>> Subject: Re: [Slony1-general] Replacing PostgreSQL 8.2 by Pg 8.3 
>>> does not work
>>>
>>> Outch I can't dump the table oid (misunderstand between table oids 
>>> and column oids). I'll look at the slonik code for the repair command.
>>>
>>> Cyril Scetbon a écrit :
>>>    
>>>> you are right !
>>>>
>>>> mydb=# select oid,relname from pg_class where relname = 't_512';
>>>>  oid  | relname
>>>> -------+---------
>>>> 69187 | t_512
>>>> (1 row)
>>>>
>>>> mydb=# select * from _pns_slony_voila_preprod_1.sl_table where       
>>> tab_relname='t_512';
>>>    
>>>> tab_id | tab_reloid | tab_relname | tab_nspname | tab_set | 
>>>> tab_idxname |       
>>> tab_altered |             tab_comment            
>>> --------+------------+-------------+-------------+---------+-------------+-------------+------------------------------------- 
>>>
>>>    
>>>>    512 |      24638 | t_512       | public      |       1 | 
>>>> t_512_pkey  | t          
>>>        | Table public.t_512 with primary key
>>>    
>>>> (1 row)
>>>>
>>>> But, repair does not work correctly, and I can't debug it (tried by 
>>>> looking in       
>>> the postgresql query log, but found nothing)
>>>    
>>>> I'll try by dumping/reloading with oid. Any idea why the repair 
>>>> command does       
>>> not work correctly ? I don't see updates on the node I want to be 
>>> repaired. I used the following script :
>>>    
>>>> echo > /var/tmp/repair.sql
>>>> slonik_print_preamble --config /etc/slony1/slon_tools_mydb.conf >> 
>>>>       
>>> /var/tmp/repair.sql
>>>    
>>>> for set in `seq 1 31`
>>>> do
>>>>  echo "REPAIR CONFIG (SET ID = $set, EVENT NODE = 101, EXECUTE ONLY 
>>>> ON =103);"      
>>>>> /var/tmp/repair.sql
>>>>>         
>>>> done
>>>> slonik < /var/tmp/repair.sql
>>>>
>>>> I got no error but nothing seems to be done
>>>>
>>>> thx
>>>>
>>>> chris a écrit :
>>>>      
>>>>> Cyril Scetbon writes:
>>>>>  
>>>>>        
>>>>>> Alan Hodgson a écrit :
>>>>>>             
>>>>>>> On Monday 10 August 2009, Cyril Scetbon
>>>>>>> wrote:
>>>>>>>                   
>>>>>>>> However, when slony is started with pg 8.3 it does not see new 
>>>>>>>> events
>>>>>>>> from his provider (still in pg8.3).
>>>>>>>> If we restart our pg 8.2 with slony it works !
>>>>>>>>
>>>>>>>> Do you know what we are missing ?
>>>>>>>>
>>>>>>>> thx
>>>>>>>>                          
>>>>>>> You need to modify all the table and sequence OIDs stored in the
>>>>>>> slony configuration tables to reflect the new table and sequence
>>>>>>> OIDs.
>>>>>>>                    
>>>>>> I don't think oids are used and table id were not modified
>>>>>>              
>>>>> No, Alan's quite right.
>>>>>
>>>>> If you look at sl_table and sl_sequence, you'll find "reloid" 
>>>>> columns,
>>>>> which are indeed relevant.
>>>>>
>>>>>  
>>>>>        
>>>>>>> You need to update the slony functions through the appropriate slon
>>>>>>> commands.
>>>>>>>                    
>>>>>> really ?
>>>>>>              
>>>>> The slonik "repair config" command should be useful.
>>>>>
>>>>>
>>>>>
>>>>> "Resets the name-to-oid mapping of tables in a replication set, 
>>>>> useful
>>>>> for restoring a node after a pg_dump."
>>>>>  
>>>>>         
>>> -- Cyril SCETBON
>>> _______________________________________________
>>> Slony1-general mailing list
>>> Slony1-general at lists.slony.info
>>> http://lists.slony.info/mailman/listinfo/slony1-general
>>>     
>>
>>
>>
>>         
>

-- 
Cyril SCETBON - Ingénieur bases de données
Cellule bases de données
AUSY pour France Télécom - OPF/PORTAILS/DOP/HEBEX

Tél : +33 (0)4 97 12 87 60
Jabber : cscetbon at jabber.org
France Telecom - Orange
790 Avenue du Docteur Maurice Donat 
Bâtiment Marco Polo C1 - Bureau 202
06250 Mougins
France

***********************************
Ce message et toutes les pieces jointes (ci-apres le 'message') sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration. Le Groupe France
Telecom decline toute responsabilite au titre de ce message s'il a ete
altere, deforme ou falsifie.
Si vous n'etes pas destinataire de ce message, merci de le detruire
immediatement et d'avertir l'expediteur.
***********************************
This message and any attachments (the 'message') are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. France Telecom Group shall not be
liable for the message if altered, changed or falsified.
If you are not recipient of this message, please cancel it immediately and
inform the sender.
************************************