From steve at ssinger.info Wed Aug 1 12:32:47 2018 From: steve at ssinger.info (Steve Singer) Date: Wed, 1 Aug 2018 15:32:47 -0400 (EDT) Subject: [Slony1-general] Inconsistent regex handling between SET ADD TABLE and SEQUENCE In-Reply-To: References: Message-ID: On Wed, 6 Jun 2018, Steve Singer wrote: > On Wed, 6 Jun 2018, Marek Becka wrote: > >> Hello, >> >> >> since Slony-I 2.1 a POSIX regular expresions can be used for adding >> tables and sequences to a replication set. I have tried to add all >> tables using Slony 2.2.5 documentation example of command SET ADD TABLE: >> >> SET ADD TABLE (SET ID=1, TABLES='public\\.tracker*'); >> >> In this case backslash must be escaped to get intended regular expression. >> >> >> Regular expresions used with SET ADD SEQUENCE doesn't works correctly >> with doubled backslash. To select all sequences from public schema plain >> regular expression must be used: >> >> SET ADD SEQUENCE (SET ID=1, SEQUENCES='public\.*'); >> >> >> Shouldn't be both command handled consistently? > > Yes, it probably should. This looks like a bug > I have pushed a fix for this to master and REL_2_2_STABLE >> >> >> _______________________________________________ >> Slony1-general mailing list >> Slony1-general at lists.slony.info >> http://lists.slony.info/mailman/listinfo/slony1-general >> > > _______________________________________________ > Slony1-general mailing list > Slony1-general at lists.slony.info > http://lists.slony.info/mailman/listinfo/slony1-general > From steve at ssinger.info Mon Aug 20 18:55:14 2018 From: steve at ssinger.info (Steve Singer) Date: Mon, 20 Aug 2018 21:55:14 -0400 (EDT) Subject: [Slony1-general] Slony 2.2.7 released Message-ID: The Slony team is pleased to announce Slony 2.2.7 the next minor release of the Slony 2.2.x series Slony 2.2.7 includes the following changes - Fix warning with flex 2.6+ - Fix compile errors with PG11 - Fix bug in with regex in 'set add sequence' when specifying the sequence as a regular expression. It was not being escaped properly - Add support to Slonik to specify the share direcotry using the environment variable SLONY_SHARE_DIR - Add slon config setting remote_listen_serializable_transactions to use read committed instead of read-only-serializable deferable transactions(default true) - Add slon config setting enable_version_check to disable the slony version check that ensures all nodes run the same slony version (default true, version check enabled) Slony 2.2.7 can be downloaded from the following URL http://www.slony.info/downloads/2.2/source/slony1-2.2.7.tar.bz2 From andy.dossett at btinternet.com Fri Aug 24 01:37:05 2018 From: andy.dossett at btinternet.com (andy.dossett at btinternet.com) Date: Fri, 24 Aug 2018 08:37:05 +0000 (UTC) Subject: [Slony1-general] enable_version_check Message-ID: 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? Thanks ?Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.slony.info/pipermail/slony1-general/attachments/20180824/4cd187e1/attachment.htm From steve at ssinger.info Sun Aug 26 18:28:00 2018 From: steve at ssinger.info (Steve Singer) Date: Sun, 26 Aug 2018 21:28:00 -0400 (EDT) Subject: [Slony1-general] enable_version_check In-Reply-To: References: Message-ID: 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 > > > > From david at fetter.org Thu Aug 30 07:47:30 2018 From: david at fetter.org (David Fetter) Date: Thu, 30 Aug 2018 16:47:30 +0200 Subject: [Slony1-general] Changing to EXTENSIONs: Multiple versions? Message-ID: <20180830144730.GE12032@fetter.org> Folks, I'd like to change Slony to use the PostgreSQL EXTENSION infrastructure, which didn't exist when Slony was first created. Making the part that lives inside the database an EXTENSION would get it to play much nicer with other parts of the system, most notably pg_dump(all) and pg_restore. However, the easiest way to do this would be to disallow running multiple versions of Slony in the same database. Are there people using that capability now, and if it went away, would it cause you a lot of inconvenience? Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate From andy.dossett at btinternet.com Fri Aug 31 06:56:06 2018 From: andy.dossett at btinternet.com (Andy Dossett) Date: Fri, 31 Aug 2018 14:56:06 +0100 Subject: [Slony1-general] enable_version_check In-Reply-To: References: Message-ID: <004a01d44132$5db54cc0$191fe640$@btinternet.com> 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 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 > > > > From ttignor at akamai.com Fri Aug 31 07:14:48 2018 From: ttignor at akamai.com (Tignor, Tom) Date: Fri, 31 Aug 2018 14:14:48 +0000 Subject: [Slony1-general] enable_version_check In-Reply-To: <004a01d44132$5db54cc0$191fe640$@btinternet.com> References: <004a01d44132$5db54cc0$191fe640$@btinternet.com> Message-ID: <1BDF40B8-481C-423C-B36E-384DD6BD8071@akamai.com> 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" 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 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 From steve at ssinger.info Fri Aug 31 15:24:47 2018 From: steve at ssinger.info (Steve Singer) Date: Fri, 31 Aug 2018 18:24:47 -0400 (EDT) Subject: [Slony1-general] enable_version_check In-Reply-To: <004a01d44132$5db54cc0$191fe640$@btinternet.com> References: <004a01d44132$5db54cc0$191fe640$@btinternet.com> Message-ID: 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 > 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 >> >> >> >> > >