MIME-Version: 1.0
References: 
 <CAEze2WiA-4EZ5Pfnr6Gw-2VGqq528_jJR=vCHNBEWoOA2vR4rg@mail.gmail.com>
 <202603161503.oft3hnonplyi@alvherre.pgsql>
 <CAEze2WjSfPzReJXJ6r0UeheDv3f1Hya71m=-Kkc1cNS5Cx4qjw@mail.gmail.com>
 <107398.1773692114@localhost>
In-Reply-To: <107398.1773692114@localhost>
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
Date: Mon, 16 Mar 2026 22:50:04 +0100
Message-ID: 
 <CAEze2WiixXk+58DTJ+JX6+q-fuX=TFNc3yTLMrbZh17=sLCY2g@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: Antonin Houska <ah@cybertec.at>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>,
 Robert Treat <rob@xzilla.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAEze2WiixXk%2B58DTJ%2BJX6%2Bq-fuX%3DTFNc3yTLMrbZh17%3DsLCY2g%40mail.gmail.com>
Precedence: bulk

On Mon, 16 Mar 2026 at 21:15, Antonin Houska <ah@cybertec.at> wrote:
>
> Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
>
> > I agree it's not user-friendly, but that's the point of limiting
> > permissions. Users can't install c-functions without SUPERUSER,
> > because it can cause cluster instability and crashes. Users can't
> > create slots without REPLICATION, because they'll be able to
> > negatively impact the whole cluster's performance, and possibly,
> > stability, when taking up replication slots that otherwise would be
> > used for critical HA purposes.
>
> I thought these attributes exist primarily for security purposes.

Well, yes, but operational security is also security, right?

> If
> non-SUPERUSER user could install C-functions, it'd be easy to install code
> that leaks data.

Yes, as long as they're able to find the right primitives in the
available binaries. That's certainly possible, but a bit more work
than just none.

> REPLICATION is currently the only way to limit access to the
> the publisher's data as there is no ACL for publications.
> And regarding resources, the REPLICATION attribute alone does not pose a limit
> on resource consumption unless you limit the total number of sessions of all
> the REPLICATION users at the same time.

True. It's not great. And we also don't really have a (good)
distinction for logical/physical replication permissions either...

> Anyway (fortunately?), the concurrent use of slots by REPACK is limited
> because, during the initialization of logical decoding, the backend needs to
> wait for all the transactions having XID assigned to finish, and these include
> the already running REPACK commands. See SnapBuildWaitSnapshot() and callers
> if you're interested in details.

Huh, so would you be able to run more than one Repack Concurrently in
the same database? ISTM that would not be possible, apart from
possibly a mechanism comparable to the SAFE_IN_IC flag (to not wait on
those backends).

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)