From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Andrey Klychkov <aaklychkov@mail.ru>
To: Victor Yegorov <vyegorov@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Alter index rename concurrently to
Date: Wed, 18 Jul 2018 11:20:57 +0200
Message-ID: <6cf6b35f-b730-60fc-bab7-82699dca59ed@2ndquadrant.com> (raw)
In-Reply-To: <1531828116.497549417@f411.i.mail.ru>
References: <1531767486.432607658@f357.i.mail.ru>
<CAGnEboiyFkmGbQFAvc+tViayyPnbJkWTd93kvmhhML+cQQ_OkA@mail.gmail.com>
<1531828116.497549417@f411.i.mail.ru>
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...
> -
> 2013 https://www.postgresql.org/message-id/CAB7nPqSTFkuc7dZxCDX4HOTU63YXHRroNv2aoUzyD-Zz_8Z_Zg@mail.gmail...
> - 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter.eisentraut@2ndquadrant.com, aaklychkov@mail.ru, vyegorov@gmail.com
Subject: Re: Alter index rename concurrently to
In-Reply-To: <6cf6b35f-b730-60fc-bab7-82699dca59ed@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox