With no more information I gave up this method and now we're using drop 
node + store node + subscribe method.

Cyril Scetbon a écrit :
> Another important information : we are using Slony 1.2.15 (it says 
> that Slony is compatible with PostgreSQL 8.3 since version 1.2.13)
>
> Cyril Scetbon a écrit :
>> 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