Re: REINDEX CONCURRENTLY 2.0

On Thu, Nov 13, 2014 at 10:25 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Andres Freund wrote:
>> On 2014-11-12 18:23:38 -0500, Robert Haas wrote:
>
>> > > The problem is that it's very hard to avoid the wrong index's
>> > > relfilenode being used when swapping the relfilenodes between two
>> > > indexes.
>> >
>> > How about storing both the old and new relfilenodes in the same pg_class entry?
>>
>> That's quite a cool idea
>>
>> [think a bit]
>>
>> But I think it won't work realistically. We have a *lot* of
>> infrastructure that refers to indexes using it's primary key.
>
> Hmm, can we make the relmapper do this job instead of having another
> pg_class column? Essentially the same sketch Robert proposed, instead
> we would initially set relfilenode=0 and have all onlookers use the
> relmapper to obtain the correct relfilenode; switching to the new
> relfilenode can be done atomically, and un-relmap the index once the
> process is complete.
> The difference from what Robert proposes is that the transient state is
> known to cause failures for anyone not prepared to deal with it, so it
> should be easy to spot what places need adjustment.

How would the failure handling actually work? Would we need some extra
process to remove the extra relfilenodes? Note that in the current
patch the temporary concurrent entry is kept as INVALID all the time,
giving the user a path to remove them with DROP INDEX even in the case
of invalid toast indexes in catalog pg_toast.

Note that I am on the side of using the exclusive lock when swapping
relfilenodes for now in any case, that's what pg_repack does by
renaming the indexes, and people use it.
--
Michael