On 2013-03-28 17:35:08 -0400, Bruce Momjian wrote:
> On Thu, Mar 28, 2013 at 10:31:51PM +0100, anara...@anarazel.de wrote:
> >
> >
> > Tom Lane schrieb:
> >
> > >Bruce Momjian writes:
> > >> Should I just patch pg_upgrade to remove the "indisvalid", skip
> > >> "indisvalid" indexes, and backpa
"anara...@anarazel.de" writes:
> 9.2 represents inisdead as live && !ready, doesn't it? So just looking at
> indislive will include about to be dropped or partially dropped indexes?
Ooooh ... you're right, in 9.2 (only) we need to check both indisvalid
and indisready (cf IndexIsValid() macro in
On 2013-03-28 17:54:08 -0400, Bruce Momjian wrote:
> On Thu, Mar 28, 2013 at 10:47:55PM +0100, anara...@anarazel.de wrote:
> >
> >
> > Tom Lane schrieb:
> >
> > >"anara...@anarazel.de" writes:
> > >> Tom Lane schrieb:
> > >>> Yeah, if you can just ignore !indisvalid indexes that should work
> >
On Thu, Mar 28, 2013 at 10:47:55PM +0100, anara...@anarazel.de wrote:
>
>
> Tom Lane schrieb:
>
> >"anara...@anarazel.de" writes:
> >> Tom Lane schrieb:
> >>> Yeah, if you can just ignore !indisvalid indexes that should work
> >fine.
> >>> I see no need to look at indisready if you're doing that
Tom Lane schrieb:
>"anara...@anarazel.de" writes:
>> Tom Lane schrieb:
>>> Yeah, if you can just ignore !indisvalid indexes that should work
>fine.
>>> I see no need to look at indisready if you're doing that.
>
>> You need to look at inisready in 9.2 since thats used for about to be
>dropped
"anara...@anarazel.de" writes:
> Tom Lane schrieb:
>> Yeah, if you can just ignore !indisvalid indexes that should work fine.
>> I see no need to look at indisready if you're doing that.
> You need to look at inisready in 9.2 since thats used for about to be dropped
> indexes. No?
No, he doesn
On Thu, Mar 28, 2013 at 10:31:51PM +0100, anara...@anarazel.de wrote:
>
>
> Tom Lane schrieb:
>
> >Bruce Momjian writes:
> >> Should I just patch pg_upgrade to remove the "indisvalid", skip
> >> "indisvalid" indexes, and backpatch it? Users should be using the
> >> version of pg_upgrade to ma
Tom Lane schrieb:
>Bruce Momjian writes:
>> Should I just patch pg_upgrade to remove the "indisvalid", skip
>> "indisvalid" indexes, and backpatch it? Users should be using the
>> version of pg_upgrade to match new pg_dump. Is there any case where
>> they don't match? Do I still need to che
Bruce Momjian writes:
> Should I just patch pg_upgrade to remove the "indisvalid", skip
> "indisvalid" indexes, and backpatch it? Users should be using the
> version of pg_upgrade to match new pg_dump. Is there any case where
> they don't match? Do I still need to check for "indisready"?
Yeah,
On Tue, Mar 26, 2013 at 09:43:54PM +, Tom Lane wrote:
> Ignore invalid indexes in pg_dump.
>
> Dumping invalid indexes can cause problems at restore time, for example
> if the reason the index creation failed was because it tried to enforce
> a uniqueness condition not satisfied by the table's
On Wed, Mar 27, 2013 at 6:47 AM, Tom Lane wrote:
> Michael Paquier writes:
> > On top of checking indisvalid, I think that some additional checks on
> > indislive and indisready are also necessary.
>
> Those are not necessary, as an index that is marked indisvalid should
> certainly also have th
Michael Paquier writes:
> On top of checking indisvalid, I think that some additional checks on
> indislive and indisready are also necessary.
Those are not necessary, as an index that is marked indisvalid should
certainly also have those flags set. If it didn't require making two
new version di
On Thu, Mar 21, 2013 at 12:58 AM, Tom Lane wrote:
> I had been on the fence about what to do here, but I find Josh's
> arguments persuasive, particularly the second one. Why shouldn't we
> consider an in-progress index to be an uncommitted DDL change?
>
> (Now admittedly, there won't *be* any un
Josh Kupershmidt writes:
> On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs wrote:
>> Invalid also means currently-in-progress, so it would be better to keep them
>> in.
> For invalid indexes which are left hanging around in the database, if
> the index definition is included by pg_dump, it will li
On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs wrote:
> On 20 March 2013 02:51, Michael Paquier wrote:
>
>> If failures happen with CREATE INDEX CONCURRENTLY, the system will be let
>> with invalid indexes. I don't think that the user would like to see invalid
>> indexes of
>> an existing system be
On 20 March 2013 02:51, Michael Paquier wrote:
> If failures happen with CREATE INDEX CONCURRENTLY, the system will be let
> with invalid indexes. I don't think that the user would like to see invalid
> indexes of
> an existing system being recreated as valid after a restore.
> So why not removin
Hi,
If failures happen with CREATE INDEX CONCURRENTLY, the system will be let
with invalid indexes. I don't think that the user would like to see invalid
indexes of
an existing system being recreated as valid after a restore.
So why not removing from a dump invalid indexes with something like the
17 matches
Mail list logo