|From:||Andreas Karlsson <andreas(at)proxel(dot)se>|
|To:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|Cc:||PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: REINDEX CONCURRENTLY 2.0|
|Views:||Raw Message | Whole Thread | Download mbox|
On 03/02/2017 03:10 AM, Michael Paquier wrote:
> On Wed, Mar 1, 2017 at 2:21 AM, Andreas Karlsson <andreas(at)proxel(dot)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,
> + // 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
> 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.
|Next Message||Thomas Munro||2017-03-13 02:20:32||Re: make async slave to wait for lsn to be replayed|
|Previous Message||David Rowley||2017-03-13 01:50:53||Re: [NOVICE] Why is there a doubtful copyObject call in add_vars_to_targetlist|