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
