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

Re: pg_upgrade problem with invalid indexes

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade problem with invalid indexes
Date: 2012-12-07 09:16:56
Message-ID: CA+U5nMJ40uvG14S+2jvSHqEhBucEXn3iVtbQVNXTfr+J2X1YZQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 7 December 2012 04:02, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Andrew Dunstan wrote:
>>
>> On 12/06/2012 09:23 PM, Bruce Momjian wrote:
>
>> >As soon as pg_dump stopped dumping the CREATE INDEX, pg_upgrade would
>> >stop creating creating it in the new cluster, and not transfer the index
>> >files.
>>
>> So we'll lose the index definition and leave some files behind? This
>> sounds a bit messy to say the least.
>
> I find it hard to get excited about this being a real problem.  If the
> index has been kept invalid, how come the definition is so valuable?

Agreed.

I don't see the problem... just say "rebuild any invalid indexes
before you run pg_upgrade".

I don't think pg_upgrade should take the responsibility of fixing
everything broken before you run an upgrade. Making that rod for our
backs looks pretty bad here and could get worse if other situations
come to light.

Maybe it should have a mode where it detects that it would fail if you
attempted the upgrade...

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


In response to

Responses

pgsql-hackers by date

Next:From: Albe LaurenzDate: 2012-12-07 11:24:56
Subject: Re: [v9.3] writable foreign tables
Previous:From: Kyotaro HORIGUCHIDate: 2012-12-07 08:58:26
Subject: Re: Performance Improvement by reducing WAL for Update Operation

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