Re: Alter index rename concurrently to

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andrey Klychkov <aaklychkov(at)mail(dot)ru>, Victor Yegorov <vyegorov(at)gmail(dot)com>
Subject: Re: Alter index rename concurrently to
Date: 2018-08-14 06:33:26
Message-ID: 8cba25b5-e7c7-de36-7886-5488b37ec521@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v1-0001-Lower-lock-level-for-renaming-indexes.patch text/plain 10.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-08-14 06:44:46 Re: Alter index rename concurrently to
Previous Message Masahiko Sawada 2018-08-14 04:38:23 Re: Copy function for logical replication slots