On Wednesday, September 26, 2012 02:39:36 PM Michael Paquier wrote:
> Do you think it is acceptable to consider that the user has to do the
> cleanup of the old or new index himself if there is a failure?
The problem I see is that if you want the thing to be efficient you might end up
doing step 1) for all/a bunch of indexes, then 2), then .... In that case you
can have loads of invalid indexes around.
> You could also reissue the reindex command and avoid an additional command.
> When launching a concurrent reindex, it could be possible to check if there
> is already an index that has been created to replace the old one that failed
> previously. In order to control that, why not adding an additional field in
> pg_index?
> When creating a new index concurrently, we register in its pg_index entry
> the oid of the index that it has to replace. When reissuing the command
> after a failure, it is then possible to check if there is already an index
> that has been issued by a previous REINDEX CONCURRENT command and based on
> the flag values of the old and new indexes it is then possible to replay the
> command from the step where it previously failed.
I don't really like this idea but we might end up there anyway because we
probably need to keep track whether an index is actually only a "replacement"
index that shouldn't exist on its own. Otherwise its hard to know which
indexes to drop if it failed halfway through.
Greetings,
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
