Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 03/02/2017 03:10 AM, Michael Paquier wrote:
> On Wed, Mar 1, 2017 at 2:21 AM, Andreas Karlsson <andreas@proxel.se> wrote:
> +    /*
> +     * Copy contraint flags for old index. This is safe because the old index
> +     * guaranteed uniquness.
> +     */
> +    newIndexForm->indisprimary = oldIndexForm->indisprimary;
> +    oldIndexForm->indisprimary = false;
> +    newIndexForm->indisexclusion = oldIndexForm->indisexclusion;
> +    oldIndexForm->indisexclusion = false;
> [...]
> +        deleteDependencyRecordsForClass(RelationRelationId, newIndexOid,
> +                                        RelationRelationId, DEPENDENCY_AUTO);
> +        deleteDependencyRecordsForClass(RelationRelationId, oldIndexOid,
> +                                        ConstraintRelationId,
> DEPENDENCY_INTERNAL);
> +
> +        // TODO: pg_depend for old index?

Spotted one of my TODO comments there so I have attached a patch where I 
have cleaned up that function. I also fixed the the code to properly 
support triggers.

> There is a lot of mumbo-jumbo in the patch to create the exact same
> index definition as the original one being reindexed, and that's a
> huge maintenance burden for the future. You can blame me for that in
> the current patch. I am wondering if it would not just be better to
> generate a CREATE INDEX query string and then use the SPI to create
> the index, and also do the following extensions at SQL level:
> - Add a sort of WITH NO DATA clause where the index is created, so the
> index is created empty, and is marked invalid and not ready.
> - Extend pg_get_indexdef_string() with an optional parameter to
> enforce the index name to something else, most likely it should be
> extended with the WITH NO DATA/INVALID clause, which should just be a
> storage parameter by the way.
> By doing something like that what the REINDEX CONCURRENTLY code path
> should just be careful about is that it chooses an index name that
> avoids any conflicts.

Hm, I am not sure how much that would help since a lot of the mumb-jumbo 
is by necessity in the step where we move the constraints over from the 
old index to the new.

Andreas

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