From: Andrey Klychkov <aaklychkov@mail.ru>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Victor Yegorov <vyegorov@gmail.com>
Subject: Re[2]: Alter index rename concurrently to
Date: Mon, 23 Jul 2018 16:14:00 +0300
Message-ID: <1532351640.49157224@f473.i.mail.ru> (raw)
In-Reply-To: <6cf6b35f-b730-60fc-bab7-82699dca59ed@2ndquadrant.com>
References: <1531767486.432607658@f357.i.mail.ru>
<1531828116.497549417@f411.i.mail.ru>
<6cf6b35f-b730-60fc-bab7-82699dca59ed@2ndquadrant.com>
>Среда, 18 июля 2018, 12:21 +03:00 от Peter Eisentraut <peter.eisentraut@2ndquadrant.com>:
>
>
>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.
I was thinking about it and I seem that AccessShareExclusiveLock by default is a better way than
the lower lock level because it corresponds to the principle of more strict implementation
of changing database schema (by default).
I think if some users need to rename a relation without query locking they should
say it definitely by using "concurrently" keyword like in the drop/create index cases.
Otherwise, to set the lower lock level we must also embody new keyword for "alter.. rename" to allow user
to set up stronger lock level for this action (not only indexes but tables and so on).
Moreover, if you rename Table without query locking, it may crushes your services that
do queries at the same time, therefore , this is unlikely that someone will be do it
with concurrent queries to renamed table, in other words, with running production.
So, I think it doesn't have real sense to use the lower lock for example for tables (at least by default).
However, renaming Indexes with the lower lock is safe for database consumers
because they don't know anything about them.
As I wrote early, in the patch I added the 'concurrent' field in the RenameStmt structure.
However, the "concurrently" keyword is realized there for index renaming only
because I only see need to rename indexes in concurrent mode.
It also may be implemented for tables, etc if it will be really needed for someone in the future.
--
Kind regards,
Andrey Klychkov
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: aaklychkov@mail.ru, peter.eisentraut@2ndquadrant.com, vyegorov@gmail.com
Subject: Re: Re[2]: Alter index rename concurrently to
In-Reply-To: <1532351640.49157224@f473.i.mail.ru>
* 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