On Mon, Jul 30, 2018 at 05:53:54PM +0900, Kyotaro HORIGUCHI wrote:
> I feel that just being a database owner doesn't justify to cause
> this problem innocently. Catalog owner is also doubious but we
> can carefully configure the ownerships to avoid the problem since
> only superuser can change it. So I vote +1 for the revised patch.
Thanks for the review. Yes that sucks that being just a database or a
schema owner allows such a user to take an exclusive lock on shared
catalogs. Please note that depending on the order of the relations,
authentication may or may not be blocked depending on what kind of locks
the second session takes.
> | Parameters
> ...
> | SYSTEM
> | Recreate all indexes on system catalogs within the current
> | database. *Indexes on shared system catalogs are included*.
> | Indexes on user tables are not processed. This form
> | of REINDEX cannot be executed inside a transaction block.
This looks correct to me, shared catalogs are included, and the "notes"
section clealy mentions that being an owner of the shared catalog is
required.
> This apparently changes the documented behavior and the problem
> seems to be a result of a rather malicious/intentional
> combination of operatoins (especially named vacuum on a shared
> catalog). I vote -0.5 to backpatch unless we categorize this as a
> security issue.
Ask that to any vendors doing shared hosting of Postgres :)
A backpatch looks like the correct course of events to me. Anybody here
is free to express his/her concerns of course.
--
Michael
