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

From: Karl Denninger <karl(at)denninger(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails
Date: 2012-05-28 16:53:35
Message-ID: 4FC3AD8F.9020005@denninger.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 5/28/2012 11:44 AM, Tom Lane wrote:
> 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.
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 /*does*/ work; you have to
specify that you want the WAL records during the pg_basebackup (e.g.
"-x=stream") so you have the WAL files for the old binary to consider
during the startup (or manually ship them after the backup completes.)

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

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-05-28 16:55:16 Re: Re: [GENERAL] Forcefully adding a CHECK constrained
Previous Message Tom Lane 2012-05-28 16:44:52 Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-28 17:11:53 Re: WalSndWakeup() and synchronous_commit=off
Previous Message Tom Lane 2012-05-28 16:48:41 Re: proclock table corrupted