>Среда, 18 июля 2018, 12:21 +03:00 от Peter Eisentraut
><peter.eisentr...@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
