Hi, On Thu, Aug 27, 2026 at 11:16 AM Matheus Alcantara <[email protected]> wrote: > > On 27/08/26 12:46, Nathan Bossart wrote: > > The REPACK decoding worker doesn't pass BGWORKER_BYPASS_ALLOWCONN like > > parallel.c does, so it can fail to start. Here is a reproducer: > > > > CREATE DATABASE d; > > REVOKE CONNECT ON DATABASE d FROM PUBLIC; > > \c d > > CREATE ROLE r NOLOGIN; > > CREATE TABLE t (a INT PRIMARY KEY); > > ALTER TABLE t OWNER TO r; > > REPACK t; -- works > > REPACK (CONCURRENTLY) t; -- fails > > > > That last command produces the following output: > > > > ERROR: permission denied for database "d" > > DETAIL: User does not have CONNECT privilege. > > CONTEXT: REPACK decoding worker > > > > This one seems easy enough to fix. > > > 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 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? I think we need to backpatch this fix to PG19 to get consistent behavior. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
