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 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
and indisready are also necessary. As indisready has been introduced in 8.3
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
Perhaps this patch should be backpatched to previous versions in order to
the same consistent behavior.


Attachment: 20130321_no_dump_indisvalid.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to