Re: Alter index rename concurrently to

Corey Huinker <corey.huinker@gmail.com>

From: Corey Huinker <corey.huinker@gmail.com>
To: peter.eisentraut@2ndquadrant.com
Cc: aaklychkov@mail.ru, pgsql-hackers@postgresql.org, vyegorov@gmail.com
Date: 2018-07-25T23:58:12Z
Lists: pgsql-hackers
>
> You appear to be saying that you think that renaming an index
> concurrently is not safe.  In that case, this patch should be rejected.
> However, I don't think it necessarily is unsafe.  What we need is some
> reasoning about the impact, not a bunch of different options that we
> don't understand.
>

I've had this same need, and dreamed this same solution before. I also
thought about a syntax like ALTER INDEX foo RENAME TO
WHATEVER-IT-WOULD-HAVE-BEEN-NAMED-BY-DEFAULT to aid this situation.

But all of those needs fade if we have REINDEX CONCURRENTLY. I think that's
where we should focus our efforts.

A possible side effort into something like a VACUUM FULL CONCURRENTLY,
which would essentially do what pg_repack does, but keeping the same oid
and the stats that go with it, but even that's a nice-to-have add-on to
REINDEX CONCURRENTLY.

Commits

  1. Lower lock level for renaming indexes