Re: Ignore invalid indexes in pg_dump

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Kupershmidt <schmiddy@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2013-03-20T15:58:26Z
Lists: pgsql-hackers
Josh Kupershmidt <schmiddy@gmail.com> writes:
> On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs <simon@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 is included by pg_dump, it will likely cause pain
> during the restore. If the index build failed the first time and
> hasn't been manually dropped and recreated since then, it's a good bet
> it will fail the next time. Errors during restore can be more than
> just a nuisance; consider restores with --single-transaction.

> And if the index is simply currently-in-progress, it seems like the
> expected behavior would be for pg_dump to ignore it anyway. We don't
> include other DDL objects which are not yet committed while pg_dump is
> running.

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.)

			regards, tom lane