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

From Tom Lane
Subject Re: Ignore invalid indexes in pg_dump
Date
Msg-id 4468.1363795106@sss.pgh.pa.us
Whole thread Raw
In response to Re: Ignore invalid indexes in pg_dump  (Josh Kupershmidt <schmiddy@gmail.com>)
Responses Re: Ignore invalid indexes in pg_dump  (Michael Paquier <michael.paquier@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Josh Kupershmidt
Date:
Subject: Re: Ignore invalid indexes in pg_dump
Next
From: Thom Brown
Date:
Subject: Re: [pgsql-advocacy] Call for Google Summer of Code mentors, admins