Re: Adding REPACK [concurrently]

On Mon, 16 Mar 2026 at 21:15, Antonin Houska <ah(at)cybertec(dot)at> wrote:
>
> Matthias van de Meent <boekewurm+postgres(at)gmail(dot)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)