Karl Denninger <karl@xxxxxxxxxxxxx> 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.
Actually when pg_upgrade starts it starts the old binary against the
old data directory first, and thus replays the WAL records until it
reaches consistency before it does the upgrade. 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.
That sounds like a bug, or poorly sequenced error checks.
regards, tom lane
Well, at least I know why it fails and that it's a bad error message
(and can't work) rather than something stupid in the original setup
(which looked ok.)