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/cab7npqtys6juqdxuczbjb0bnw0kprw8wdzuk11kaxqq6o98...@mail.gmail.com > - > 2013 > https://www.postgresql.org/message-id/cab7npqstfkuc7dzxcdx4hotu63yxhrronv2aouzyd-zz_8z...@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
