On Wed, Dec 7, 2011 at 6:53 PM, Tory M Blue wrote:
> Well thought it was maybe just going from 8.4.4 to 9.1.1 so upgraded
> to 8.4.9 and tried pg_upgrade again (this is 64bit) and it's failing
>
> -bash-4.0$ /tmp/pg_upgrade --check --old-datadir "/data/db"
> --new-datadir "/data1/db" --old-bindir
Tory M Blue wrote:
> >From my last report I had success but it was successful due to lots of
> manual steps. I figured it may be safer to just create a new rpm,
> installing to pgsql9 specific directories and a new data directory.
>
> This allows pg_upgrade to complete successfully (so it says). H
Well thought it was maybe just going from 8.4.4 to 9.1.1 so upgraded
to 8.4.9 and tried pg_upgrade again (this is 64bit) and it's failing
-bash-4.0$ /tmp/pg_upgrade --check --old-datadir "/data/db"
--new-datadir "/data1/db" --old-bindir "/ipix/pgsql/bin" --new-bindir
"/ipix/pgsql9/bin"
Performing
>From my last report I had success but it was successful due to lots of
manual steps. I figured it may be safer to just create a new rpm,
installing to pgsql9 specific directories and a new data directory.
This allows pg_upgrade to complete successfully (so it says). However
my new data directory
On Mon, Dec 5, 2011 at 11:08 AM, Bruce Momjian wrote:
>
> If you look in a 9.0+ tablespace directory, you will see that each
> cluster has its own subdirectory:
>
> test=> create tablespace tb1 location '/u/pg/tb1';
> CREATE TABLESPACE
> test=> \q
> $ lf /u/pg/tb1
>
Tory M Blue wrote:
> On Mon, Dec 5, 2011 at 10:31 AM, Tory M Blue wrote:
> > On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian wrote:
> >>> But initial response to all this, is umm we have not really made a
> >>> dump/restore unnecessary with the latest releases of Postgres than, as
> >>> I would ha
Tory M Blue wrote:
> On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian wrote:
> >> But initial response to all this, is umm we have not really made a
> >> dump/restore unnecessary with the latest releases of Postgres than, as
> >> I would have to think that there is a high percentage of users whom
>
On Mon, Dec 5, 2011 at 10:31 AM, Tory M Blue wrote:
> On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian wrote:
>>> But initial response to all this, is umm we have not really made a
>>> dump/restore unnecessary with the latest releases of Postgres than, as
>>> I would have to think that there is a h
On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian wrote:
>> But initial response to all this, is umm we have not really made a
>> dump/restore unnecessary with the latest releases of Postgres than, as
>> I would have to think that there is a high percentage of users whom
>> use tablespaces.
>
> Yes,
Tory M Blue wrote:
> Bruce is right, I didn't move tablespaces (I didn't know to be honest
> I had to, but it makes sense). I simply moved the location of the data
> files, from /data to /data1. But I did "not", change any sym links or
I was unclear if you moved the data directory or the tablespac
On Mon, Dec 5, 2011 at 7:34 AM, Bruce Momjian wrote:
> Nicholson, Brad (Toronto, ON, CA) wrote:
>>
>> Based on the OP this does not seem like a messed up configuration. It
>> sounds like the OP used a fully supported core feature of Postgres
>> (tablespaces) and pg_upgrade failed as a result. I
agnus Hagander
> > Subject: Re: [PERFORM] pg_upgrade
> >
> > Nicholson, Brad (Toronto, ON, CA) wrote:
> > > > You mean moving tablespaces? That isn't something pg_upgrade deals
> > > > with. If we need docs to move tablespaces, it is a missing piece
>
> -Original Message-
> From: Bruce Momjian [mailto:br...@momjian.us]
> Sent: Monday, December 05, 2011 10:24 AM
> To: Nicholson, Brad (Toronto, ON, CA)
> Cc: Tory M Blue; pgsql-performance@postgresql.org; Magnus Hagander
> Subject: Re: [PERFORM] pg_upgrade
>
> Nich
Nicholson, Brad (Toronto, ON, CA) wrote:
> > You mean moving tablespaces? That isn't something pg_upgrade deals
> > with. If we need docs to move tablespaces, it is a missing piece of
> > our
> > main docs, not something pg_upgrade would ever mention.
>
> If I'm reading the issue correctly, and
> -Original Message-
> From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-
> ow...@postgresql.org] On Behalf Of Bruce Momjian
> Sent: Saturday, December 03, 2011 6:42 PM
> To: Tory M Blue
> Cc: pgsql-performance@postgresql.org
> Subject: Re:
Bruce Momjian wrote:
> Tory M Blue wrote:
> > On Sat, Dec 3, 2011 at 6:04 AM, Bruce Momjian wrote:
> >
> > > Well, I am not totally clear how you are moving things around, but I do
> > > know pg_upgrade isn't happy to have the old and new cluster be very
> > > different.
> > >
> > > What I think
Tory M Blue wrote:
> On Sat, Dec 3, 2011 at 6:04 AM, Bruce Momjian wrote:
>
> > Well, I am not totally clear how you are moving things around, but I do
> > know pg_upgrade isn't happy to have the old and new cluster be very
> > different.
> >
> > What I think is happening is that you didn't prope
On Sat, Dec 3, 2011 at 6:04 AM, Bruce Momjian wrote:
> Well, I am not totally clear how you are moving things around, but I do
> know pg_upgrade isn't happy to have the old and new cluster be very
> different.
>
> What I think is happening is that you didn't properly move the
> tablespace in the
Tory M Blue wrote:
> So we are making progress on our performance issues, we are splitting
> the data, changing the index value etc. So far having some success,
> but we also want to test out some of the options and changes in the 9
> branch, but trying to dump and restore 750gb of data is not all
ever tried symlinking?
On Dec 3, 2011 5:09 AM, "Tory M Blue" wrote:
> So we are making progress on our performance issues, we are splitting
> the data, changing the index value etc. So far having some success,
> but we also want to test out some of the options and changes in the 9
> branch, but
So we are making progress on our performance issues, we are splitting
the data, changing the index value etc. So far having some success,
but we also want to test out some of the options and changes in the 9
branch, but trying to dump and restore 750gb of data is not all that
fun, so I'm trying to
21 matches
Mail list logo
