Re: Alter index rename concurrently to

On 31/07/2018 23:10, Peter Eisentraut wrote:
> On 27/07/2018 16:16, Robert Haas wrote:
>> With respect to this particular patch, I don't know whether there are
>> any hazards of the second type.  What I'd check, if it were me, is
>> what structures in the index's relcache entry are going to get rebuilt
>> when the index name changes.  If any of those look like things that
>> something that somebody could hold a pointer to during the course of
>> query execution, or more generally be relying on not to change during
>> the course of query execution, then you've got a problem.
> 
> I have investigated this, and I think it's safe.  Relcache reloads for
> open indexes are already handled specially in RelationReloadIndexInfo().
>  The only pointers that get replaced there are rd_amcache and
> rd_options.  I have checked where those are used, and it looks like they
> are not used across possible relcache reloads.  The code structure in
> those two cases make this pretty unlikely even in the future.  Also,
> violations would probably be caught by CLOBBER_CACHE_ALWAYS.

Based on these assertions, here is my proposed patch.  It lowers the
lock level for index renaming to ShareUpdateExclusiveLock.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services