Re: pg_upgrade problem with invalid indexes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade problem with invalid indexes
Date
Msg-id 22944.1354894162@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade problem with invalid indexes  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade problem with invalid indexes
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Fri, Dec  7, 2012 at 03:32:51PM +0100, Andres Freund wrote:
>> ISTM that anybody who does DDL during or after pg_upgrade --check
>> deserves any pain.
>> 
>> So throwing an error in both seems perfectly fine for me.

I agree with Andres on this.

> I am just saying that this makes the --check report more likely to false
> failures than currently configured.

It's not a "false" failure.  If you were to force-shutdown the system at
that instant (not allowing C.I.C. to complete) then do a pg_upgrade, it
would fail.  So what's wrong with telling the user so?

If you want, you could have the error message include some weasel
wording about how this might be only a transient state, but frankly
I think that's more likely to be confusing than helpful.  As Andres
says, nobody should expect that it's sensible to do "pg_upgrade --check"
while any DDL is actively executing, so you'd be warning about a state
that more than likely isn't reality anyway.


On balance I am coming around to support the "just throw an error if
there are any invalid indexes" position.  Adding extra complication in
pg_dump and pg_upgrade to handle ignoring them doesn't seem like a good
idea --- for one thing, it will evidently weaken the strength of the
same-number-of-relations cross-check.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade problem with invalid indexes
Next
From: Heikki Linnakangas
Date:
Subject: Re: Switching timeline over streaming replication