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 <st...@ssinger.info> Sent: 27 August 2018 02:28 To: andy.doss...@btinternet.com Cc: slony1-general@lists.slony.info Subject: Re: [Slony1-general] enable_version_check On Fri, 24 Aug 2018, andy.doss...@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@lists.slony.info http://lists.slony.info/mailman/listinfo/slony1-general
