Re: [BUG] autovacuum may skip tables when session_authorization/role is set on database

From: "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUG] autovacuum may skip tables when session_authorization/role is set on database
Date: 2023-12-13 22:53:47
Message-ID: E9ADF0C6-2F7A-4564-B2F1-CB5CF61A1F4B@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> What is the actual
> use case for such a setting?

I don't have exact details on the use-case, bit this is not a common
use-case.

> Doesn't it risk security problems?

I cannot see how setting it on the database being more problematic than
setting it on a session level.

> I'm rather unimpressed by this proposal, first because there are
> probably ten other ways to break autovac with ill-considered settings,

There exists code in autovac that safeguard for such settings. For example,
statement_timeout, lock_timeout are disabled. There are a dozen or
more other settings that are overridden for autovac.

I see this being just another one to ensure that autovacuum always runs
as superuser.

> and second because if we do want to consider this a supported case,
> what about other background processes? They'd likely have issues
> as well.

I have not considered other background processes, but autovac is the only
one that I can think of which checks for relation permissions.

Regards,

Sami

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2023-12-14 00:22:11 Re: [PoC] Improve dead tuple storage for lazy vacuum
Previous Message Thomas Munro 2023-12-13 22:22:42 Obscure lwlock assertion failure if write fails in initdb