Re: Improve behavior of concurrent ANALYZE/VACUUM

On Tue, Aug 14, 2018 at 11:59 AM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On HEAD, we check the ownership of the relation vacuumed or analyzed
> after taking a lock on it in respectively vacuum_rel() and
> analyze_rel(), where we already know the OID of the relation and there
> may be no RangeVar which we could use with RangeVarGetRelidExtended
> (like partitions). I don't think that we want to use again
> RangeVarGetRelidExtended once the relation OID is known anyway.

We definitely don't want to use RangeVarGetRelidExtended more than
necessary. It is important that we use that function only when
necessary - that is, to look up names supplied by users - and it is
also important that we look up each user-supplied name only once, lest
we get different answers on different occasions, possibly introducing
either outright security problems or at the least ludicrous behavior.

In the case where we have an OID already, I think we could just
perform a permissions test before locking the OID. It's true that
permissions might be revoked after we test them and before the lock is
acquired, but that doesn't seem terrible. The real point of all of
this stuff is to keep users from locking objects which they never had
any right to access, not to worry about what happens if permissions
are concurrently revoked while we're getting the lock.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company