Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails
| От | Tom Lane |
|---|---|
| Тема | Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails |
| Дата | |
| Msg-id | 7788.1338223492@sss.pgh.pa.us обсуждение |
| Ответ на | Attempting to do a rolling move to 9.2Beta (as a slave) fails (Karl Denninger <karl@denninger.net>) |
| Ответы |
Re: Attempting to do a rolling move to 9.2Beta (as a slave)
fails
|
| Список | pgsql-general |
Karl Denninger <karl@denninger.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
В списке pgsql-general по дате отправления: