Re: Ignore invalid indexes in pg_dump - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Ignore invalid indexes in pg_dump
Date
Msg-id CAB7nPqTzuN5UgBWfVcYaA6X14JyuaGg=i8-c4r61Vg9q22HsDw@mail.gmail.com
Whole thread Raw
In response to Re: Ignore invalid indexes in pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Ignore invalid indexes in pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


On Thu, Mar 21, 2013 at 12:58 AM, Tom Lane <tgl@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 won't *be* any uncommitted ordinary DDL on tables
while pg_dump is running, because it takes AccessShareLock on all
tables.  But there could easily be uncommitted DDL against other types
of database objects, which pg_dump won't even see.)
+1. Playing it safe is a better thing to do for sure, especially if a restore would
fail. I didn't think about that first...

On top of checking indisvalid, I think that some additional checks on indislive
and indisready are also necessary. As indisready has been introduced in 8.3 and
indislive has been added in 9.3, the attached patch is good I think.
I also added a note in the documentation about invalid indexes not being dumped.
Perhaps this patch should be backpatched to previous versions in order to have
the same consistent behavior.

Regards,
--
Michael
Attachment

pgsql-hackers by date:

Previous
From: Brendan Jurd
Date:
Subject: Single-argument variant for array_length and friends?
Next
From: Noah Misch
Date:
Subject: Re: Let's invent a function to report lock-wait-blocking PIDs