Re: REPACK (CONCURRENTLY) fails when table owner lacks CONNECT

On Thu Aug 27, 2026 at 3:33 PM -03, Bharath Rupireddy wrote:
> On Thu, Aug 27, 2026 at 11:16 AM Matheus Alcantara
>> I'm attaching a patch to use BGWORKER_BYPASS_ALLOWCONN on
>> BackgroundWorkerInitializeConnectionByOid as parallel.c.
>
> +1. If a user is able to connect and run REPACK, there's no reason to
> block REPACK (CONCURRENTLY).
>
> One general concern I have: is it okay for a role that has neither the
> login privilege nor CONNECT on the database to perform logical
> decoding for concurrent repack? It may well be okay, because the
> repack worker already bypasses the login check for the role it uses to
> connect to the database.
>

I think so. IIUC the privilege decision is not made in the worker. The
leader checks ACL_MAINTAIN against the invoking user in
repack_is_permitted_for_relation(), and only then starts the worker. The
role the worker connects as is not an authorization decision, it's just
the identity the work runs under.

>> I also added a test case for it.
>
> I quickly checked and there's no test case for bypassing the login
> check. Can we add one while here?
>

Added this new test case on attached.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com