Hi Andy,
	As you've noticed, the config option is provided separately to each slon daemon in your service, so a slon before 2.2.7 isn't going to know about the option and so will still run the schema check. We also use a single provider cluster, and in our upgrade process, the replicas (slaves) are upgraded first. That worked for our upgrade from 2.2.4 (using an alpha version of the 2.2.7 changes.)
	The option in the code is a boolean. We should fix the doc.

	Tom    (
	

On 8/31/18, 9:56 AM, "Andy Dossett" <andy.dossett at btinternet.com> 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.
    
    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
    > 
    > 
    > 
    >
    
    
    _______________________________________________
    Slony1-general mailing list
    Slony1-general at lists.slony.info
    http://lists.slony.info/mailman/listinfo/slony1-general