On Fri, 31 Aug 2018, Andy Dossett wrote:

> I have carried out a basic test with the master at 2.2.7, with 
> enable_version_check ‘off’, and a slave at 2.2.3. The slave still checks 
> versions.
>
> My conclusion is that this option only has any value when master and slave 
> are at, or above, 2.2.7. The only way I can see it working for older 
> versions is if the master holds the version number of the slave and ‘lies’ 
> by reporting the stored version number when queried by the slave.

I think 'version number of the slave' is a bit misleading.

You have slonik, slon, and the stored functions.
Only the stored functions are directly tied to the version number 'of the 
slave'.

You could do something like the following.

Step 1) Upgrade all your slon processes to be 2.2.7 and set
enable_version_check=false.  Slon should start.

Step 2) Upgrade your slonik instance

Step 3) Upgrade each database and then run UPDATE FUNCTIONS on each

Set enable_version_check=true again

This of course should be tested.



>
> Here’s some snippets from the logs;
>
> 2.2.7 (master)
> 2018-08-31 14:00:05 BST [20062] CONFIG main: slon version 2.2.7 starting up
> 2018-08-31 14:00:05 BST [20063] CONFIG main: Boolean option enable_version_check = 0
>
> 2.2.3 (slave)
> 2018-08-31 14:09:17 BST [10640] CONFIG version for "host=xxx.xxx.xxx.xxx dbname=posdb user=postgres port=5432 password=abcdefg" is 90603
> 2018-08-31 14:09:17 BST [10640] ERROR  Slony-I schema version is 2.2.7
> 2018-08-31 14:09:17 BST [10640] ERROR  please upgrade Slony-I schema to version 2.2.3
> 2018-08-31 14:09:17 BST [10640] ERROR  Slony-I module version is 2.2.7
> 2018-08-31 14:09:17 BST [10640] ERROR  please upgrade Slony-I shared module to version 2.2.3
> 2018-08-31 14:09:17 BST [10640] ERROR  remoteListenThread_1: db_checkSchemaVersion() failed
>
> A few other things from the log.
>
> Both 2.2.3 and 2.2.7 warn that three config options are missing, yet complain that those same options are present! Note, no line break for the ‘not found’ warning.
> 2018-08-31 14:00:05 BST [0] WARN   conf option sync_max_rowsize not found2018-08-31 14:00:05 BST [0] WARN   unrecognized configuration parameter "sync_max_rowsize"
> 2018-08-31 14:00:05 BST [0] WARN   conf option sync_max_largemem not found2018-08-31 14:00:05 BST [0] WARN   unrecognized configuration parameter "sync_max_largemem"
> 2018-08-31 14:00:05 BST [0] WARN   conf option desired_sync_time not found2018-08-31 14:00:05 BST [0] WARN   unrecognized configuration parameter "desired_sync_time"
>
> The log says that enable_version_check is a boolean option – the documentation says it is integer.
>
> Should the password in the reporting of the connection string be obfuscated?
>
>
>
> -----Original Message-----
> From: Steve Singer <steve at ssinger.info>
> Sent: 27 August 2018 02:28
> To: andy.dossett at btinternet.com
> Cc: slony1-general at lists.slony.info
> Subject: Re: [Slony1-general] enable_version_check
>
> On Fri, 24 Aug 2018, andy.dossett at btinternet.com wrote:
>
>> Hi
>>
>> We are currently running our master server on SuSE 10 with Postgres
>> 9.3 and Slony 2.2.3. Our slaves are running on CentOS, also with Postgres 9.3 and Slony 2.2.3.
>>
>> We are running a project to upgrade the master to SuSE 12 and Postgres
>> 9.6. Unfortunately Slony 2.2.3 would not install so we went up to
>> 2.2.6. Unfortunately this means that we have to upgrade the slaves to 2.2.6 as well.
>>
>> However, 2.2.7 has just been released which includes the enable_version_check feature.
>>
>> If we went up to 2.2.7 on the master and turned version checking off,
>> would this enable master and slaves to replicate, or would the version checking in the slave prevent it?
>>
>> If turning off version checking does allow replication, are 2.2.3 and 2.2.7 compatible with each other?
>
> You should test it but there is a good chance data replication will work between them.  Just looking at the release notes I don't see anything that would obviously break data replication. Configuration events, including failovers  and DDL replication did have some changes though.
>
>
>
>>
>> Thanks
>>
>>  Andy
>>
>>
>>
>>
>
>