On 17.07.18 13:48, Andrey Klychkov wrote:
> Please, have a look at previous discussions on the subject:
> - 2012
> https://www.postgresql.org/message-id/CAB7nPqTys6JUQDxUczbJb0BNW0kPrW8WdZuk11KaxQq6o98PJg@mail.gmail.com
> -
> 2013 https://www.postgresql.org/message-id/CAB7nPqSTFkuc7dZxCDX4HOTU63YXHRroNv2aoUzyD-Zz_8Z_Zg@mail.gmail.com
> - https://commitfest.postgresql.org/16/1276/
[the above are discussions on REINDEX CONCURRENTLY]
> In the first discussion the concurrent alter was mentioned.
> In the next link and commitfest info I only saw "Reindex concurrently 2.0".
> It sounds great!
> If this component will be added to core it certainly facilitates index
> rebuilding.
>
> What about "alter index ... rename to" in the concurrent mode?
> Does "Reindex concurrently 2.0" add it?
The latest posted REINDEX CONCURRENTLY patch implements swapping index
dependencies and name with a ShareUpdateExclusiveLock, which is
effectively what your patch is doing also, for renaming only.
In the 2012 thread, it was mentioned several times that some thought
that renaming without an exclusive lock was unsafe, but without any
further reasons. I think that was before MVCC catalog snapshots were
implemented, so at that time, any catalog change without an exclusive
lock would have been risky. After that was changed, the issue hasn't
been mentioned again in the 2013 and beyond thread, and it seems that
everyone assumed that it was OK.
It we think that it is safe, then I think we should just lower the lock
level of RENAME by default.
In your patch, the effect of the CONCURRENTLY keyword is just to change
the lock level, without any further changes. That doesn't make much
sense. If we think the lower lock level is OK, then we should just use
it always.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services