Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread Andres Freund
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

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread Tom Lane
"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

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread Andres Freund
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 > >

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread Bruce Momjian
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

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread anara...@anarazel.de
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

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread Tom Lane
"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

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread Bruce Momjian
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

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread anara...@anarazel.de
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

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread Tom Lane
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,

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread Bruce Momjian
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

Re: [HACKERS] Ignore invalid indexes in pg_dump

2013-03-26 Thread Michael Paquier
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

Re: [HACKERS] Ignore invalid indexes in pg_dump

2013-03-26 Thread Tom Lane
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

Re: [HACKERS] Ignore invalid indexes in pg_dump

2013-03-20 Thread Michael Paquier
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

Re: [HACKERS] Ignore invalid indexes in pg_dump

2013-03-20 Thread Tom Lane
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

Re: [HACKERS] Ignore invalid indexes in pg_dump

2013-03-20 Thread Josh Kupershmidt
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

Re: [HACKERS] Ignore invalid indexes in pg_dump

2013-03-20 Thread Simon Riggs
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

[HACKERS] Ignore invalid indexes in pg_dump

2013-03-19 Thread Michael Paquier
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