Attempting to do a rolling move to 9.2Beta (as a slave) fails

From: Karl Denninger <karl(at)denninger(dot)net>
To: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Attempting to do a rolling move to 9.2Beta (as a slave) fails
Date: 2012-05-28 03:18:40
Message-ID: 4FC2EE90.20006@denninger.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Here's what I'm trying to do in testing 9.2Beta1.

The current configuration is a master and a hot standby at a diverse
location for both hot swap and "online" backup. Both are archived
regularly so if something goes south I can recover (to either as a master.)

I am attempting to validate the path forward to 9.2, and thus tried the
following:

1. Build 9.2Beta1; all fine.

2. Run a pg_basebackup from the current master machine (running 9.1) to
a new directory on the slave machine, using the 9.2Beta1 pg_basebackup
executable.

3. Run a pg_upgrade against that from the new binary directory,
producing a 9.2Beta1 data store.

4. Attempt to start the result as a SLAVE against the existing 9.1 master.

Everything is ok until I try to start the result as a slave. I would
think I should be able to, since this is exactly the procedure (minus
the upgrade) that I used to get the slave in operation in the first
place (although I did the archive/dump/copy to the slave machine
manually rather than use "pg_basebackup" to get it.)

But the last step fails, claiming that "wal_level was set to minimal"
when the WAL records were written. No it wasn't. Not only was it not
on the master where the base backup came from, it wasn't during the
upgrade either nor is it set that way on the new candidate slave.

Is this caused by the version mismatch? Note that it does NOT bitch
about the versions not matching. For obvious reasons I'm not interested
in rolling the production master up to 9.2 until it's released, but
running a second instance of my HA code against it as a slave would
allow me to perform a very complete set of tests against 9.2Beta1
without any hassle or operational risks, yet keep the full working data
set available and online during the testing.

Do I need to run a complete parallel environment instead of trying to
attach a 9.2Beta1 slave to an existing 9.1 master? (and if so, why
doesn't the code complain about the mismatch instead of the bogus WAL
message?)

--
-- Karl Denninger
/The Market Ticker ®/ <http://market-ticker.org>
Cuda Systems LLC

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jan Nielsen 2012-05-28 04:08:15 Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails
Previous Message Marti Raudsepp 2012-05-27 18:22:45 Re: PG vs MSSQL language comparison ?

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Nielsen 2012-05-28 04:08:15 Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails
Previous Message Noah Misch 2012-05-28 00:46:47 Re: [RFC] Interface of Row Level Security