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

Karl Denninger <karl(at)denninger(dot)net> writes:
> 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.

I do not think this can work, unless pg_basebackup is more magic than I
think it is. AFAIK, what you have after step 2 is a non-self-consistent
data directory that needs to be fixed by WAL replay before it is
consistent. And pg_upgrade needs a consistent starting point.

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

This is definitely not going to work. You can only log-ship between
servers of the same major version.

> 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.

That sounds like a bug, or poorly sequenced error checks.

regards, tom lane