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

Hi,

On Thu, Aug 27, 2026 at 11:16 AM Matheus Alcantara
<matheusssilv97(at)gmail(dot)com> 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