Skip site navigation (1) Skip section navigation (2)

Re: Problem with pg_upgrade

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Payal Singh <payals1(at)umbc(dot)edu>, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>,pgsql-bugs(at)postgresql(dot)org
Subject: Re: Problem with pg_upgrade
Date: 2012-07-06 03:37:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Thu, Jul 05, 2012 at 06:28:31PM -0400, Tom Lane wrote:
> Payal Singh <payals1(at)umbc(dot)edu> writes:
> > On Thu, Jul 5, 2012 at 12:15 PM, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> wrote:
> >> If you start 9.1 on a copy of the backup then cleanly stop it again, does
> >> pg_upgrade then run?
> > Thank you. That worked.
> ISTM that pg_upgrade should check that the old cluster was shut down
> cleanly, ie pg_control has state = "shut down".  AFAICT from some
> testing, it currently only checks that there is no file,
> which is easily bypassed by users who might not realize that it's not
> safe to run pg_upgrade against a filesystem backup.

I am confused.  pg_upgrade certainly starts/stops the old and new server
with pg_ctl before copying any files --- isn't that sufficent?

> BTW, I also noticed while trying to test this that pg_upgrade is
> currently completely broken for the case of taking PGDATAOLD or
> PGDATANEW from the environment rather than switches.  This is because
> the existing coding in option.c fails to set up the "pgconfig" fields
> in such cases.

Oh, good catch.  Fixed with the attached patch, and backpatched to 9.2.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

Attachment: pg_upgrade.diff
Description: text/x-diff (2.9 KB)

In response to


pgsql-bugs by date

Next:From: Craig RingerDate: 2012-07-06 04:35:29
Subject: Re: BUG #6720: Its often disconnecting
Previous:From: Craig RingerDate: 2012-07-06 00:12:30
Subject: Re: BUG #6720: Its often disconnecting

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group