Re: Problem with pg_upgrade

From: Payal Singh <payals1(at)umbc(dot)edu>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
Subject: Re: Problem with pg_upgrade
Date: 2012-07-06 20:32:20
Message-ID: CAK4ounzgBdD84PUjKAwdPOrk2bZBGfPbwQW=HgmbSxPazN=qTQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Okay. I guess so. Thanks for your help.

Regards,
Payal

On Fri, Jul 6, 2012 at 4:24 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Fri, Jul 06, 2012 at 04:21:06PM -0400, Payal Singh wrote:
> > If something was wrong with the cluster, why did vacuumdb on new server
> run
> > successfully when I followed Craig's suggestion of running vacuumdb on
> old
> > server first, before performing the upgrade, and then ran vacuumdb on
> new one?
>
> My guess is there is something odd about the old cluster that was
> somehow fixed by the vacuumedb on the old clsuter that can't be fixed by
> vacuumdb on the new cluster.
>
> ---------------------------------------------------------------------------
>
>
> >
> > On Fri, Jul 6, 2012 at 4:05 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > On Fri, Jul 06, 2012 at 04:03:38PM -0400, Payal Singh wrote:
> > > The omnipitr-backup-slave process takes online backups from the
> standby,
> > and
> > > this is done everyday. This process connects to the master and
> calls a
> > > pg_start_backup and then looks for a restore point on the standby
> after
> > that
> > > WAL address. So i don't think I need to shut down the server.
> >
> > My guess is if you try pg_upgrade without omnipitr-backup-slave, and
> it
> > works, odds are something about your use of omnipitr-backup-slave is
> > wrong.
> >
> > > Also, it is the omnipitr-backup-slave process that makes a separate
> > backup for
> > > xlog.
> > >
> > >
> > > If you run vacuumedb now, does everything later work fine?
> > >
> > >
> > > I'm not sure about that. Didn't try anything else after that. The
> > 9.2beta2
> > > server starts without errors though.
> >
> > True, but it seems like something it wrong about the cluster, as is
> > shown by vacuumdb.
> >
> >
> ---------------------------------------------------------------------------
> >
> >
> > >
> > > Regards,
> > > Payal
> > >
> > > On Fri, Jul 6, 2012 at 3:30 PM, Bruce Momjian <bruce(at)momjian(dot)us>
> wrote:
> > >
> > > On Fri, Jul 06, 2012 at 02:22:28PM -0400, Payal Singh wrote:
> > > > The first message in the log is probably because the backup
> is
> > taken from
> > > a
> > > > standby. I am using omnipitr-backup-slave to make the
> backups and
> > then
> > > > restoring one of those.
> > >
> > > OK, this is what I wanted to see. Is the server running while
> you
> > are
> > > taking these backups, because that will not work.
> > >
> > > > The whole process that I followed is:
> > > >
> > > >
> > > > 1. Restoring backup file:
> > > > 2.
> > > > 3. payal(at)sparedb1:/data/pg$ sudo tar -xvzf
> /mnt/nas/backups/
> > postgres/
> > > > userslave2/backups/data/
> > > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz
> > >
> > > > 489. payal(at)sparedb1:/data/pg$ sudo tar -xvzf
> /mnt/nas/backups/
> > postgres/
> > > > userslave2/backups/data/
> > > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz
> > > > 490. 9.1/pg_xlog/
> > > > 491. 9.1/pg_xlog/000000010000027C00000070
> > > > 492. 9.1/pg_xlog/000000010000027C0000006B.009707C0.backup
> > > > 493. 9.1/pg_xlog/000000010000027C0000006D
> > > > 494. 9.1/pg_xlog/000000010000027C0000006C
> > > > 495. 9.1/pg_xlog/000000010000027C0000006B
> > > > 496. 9.1/pg_xlog/000000010000027C0000006E
> > > > 497. 9.1/pg_xlog/000000010000027C00000071
> > > > 498. 9.1/pg_xlog/000000010000027C0000006F
> > >
> > > Why is the xlog backup a separate step? Because it is a
> separate
> > file
> > > system? The system is down, I assume.
> > >
> > > If you run vacuumedb now, does everything later work fine?
> > >
> > > --
> > > Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> > > EnterpriseDB
> http://enterprisedb.com
> > >
> > > + It's impossible for everything to be true. +
> > >
> > >
> > >
> > >
> > > --
> > > Payal Singh
> > > Graduate Student
> > > Department of Computer Science and Electrical Engineering
> > > University of Maryland, Baltimore County
> >
> > --
> > Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> > EnterpriseDB http://enterprisedb.com
> >
> > + It's impossible for everything to be true. +
> >
> >
> >
> >
> > --
> > Payal Singh
> > Graduate Student
> > Department of Computer Science and Electrical Engineering
> > University of Maryland, Baltimore County
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
>

--
Payal Singh
Graduate Student
Department of Computer Science and Electrical Engineering
University of Maryland, Baltimore County

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Robert Haas 2012-07-06 23:32:10 Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created
Previous Message Bruce Momjian 2012-07-06 20:24:16 Re: Problem with pg_upgrade