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
Bruce Momjian br...@momjian.us 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?
Tom Lane t...@sss.pgh.pa.us schrieb:
Bruce Momjian br...@momjian.us 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?
On Thu, Mar 28, 2013 at 10:31:51PM +0100, anara...@anarazel.de wrote:
Tom Lane t...@sss.pgh.pa.us schrieb:
Bruce Momjian br...@momjian.us writes:
Should I just patch pg_upgrade to remove the indisvalid, skip
indisvalid indexes, and backpatch it? Users should be using the
version of
anara...@anarazel.de and...@anarazel.de writes:
Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us schrieb:
anara...@anarazel.de and...@anarazel.de writes:
Tom Lane t...@sss.pgh.pa.us 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
On Thu, Mar 28, 2013 at 10:47:55PM +0100, anara...@anarazel.de wrote:
Tom Lane t...@sss.pgh.pa.us schrieb:
anara...@anarazel.de and...@anarazel.de writes:
Tom Lane t...@sss.pgh.pa.us schrieb:
Yeah, if you can just ignore !indisvalid indexes that should work
fine.
I see no need to look
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 t...@sss.pgh.pa.us schrieb:
anara...@anarazel.de and...@anarazel.de writes:
Tom Lane t...@sss.pgh.pa.us schrieb:
Yeah, if you can just ignore
anara...@anarazel.de and...@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
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 t...@sss.pgh.pa.us schrieb:
Bruce Momjian br...@momjian.us writes:
Should I just patch pg_upgrade to remove the indisvalid, skip
indisvalid indexes,
Michael Paquier michael.paqu...@gmail.com 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
On Wed, Mar 27, 2013 at 6:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Michael Paquier michael.paqu...@gmail.com 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
On 20 March 2013 02:51, Michael Paquier michael.paqu...@gmail.com 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
On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 20 March 2013 02:51, Michael Paquier michael.paqu...@gmail.com 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
Josh Kupershmidt schmi...@gmail.com writes:
On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs si...@2ndquadrant.com 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
On Thu, Mar 21, 2013 at 12:58 AM, Tom Lane t...@sss.pgh.pa.us 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
16 matches
Mail list logo
