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. > 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general