public inbox for [email protected]
help / color / mirror / Atom feedFrom: Matthias van de Meent <[email protected]>
To: Antonin Houska <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Mihail Nikalayeu <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Robert Treat <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Mon, 16 Mar 2026 22:50:04 +0100
Message-ID: <CAEze2WiixXk+58DTJ+JX6+q-fuX=TFNc3yTLMrbZh17=sLCY2g@mail.gmail.com> (raw)
In-Reply-To: <107398.1773692114@localhost>
References: <CAEze2WiA-4EZ5Pfnr6Gw-2VGqq528_jJR=vCHNBEWoOA2vR4rg@mail.gmail.com>
<[email protected]>
<CAEze2WjSfPzReJXJ6r0UeheDv3f1Hya71m=-Kkc1cNS5Cx4qjw@mail.gmail.com>
<107398.1773692114@localhost>
On Mon, 16 Mar 2026 at 21:15, Antonin Houska <[email protected]> wrote:
>
> Matthias van de Meent <[email protected]> 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)
view thread (6+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Adding REPACK [concurrently]
In-Reply-To: <CAEze2WiixXk+58DTJ+JX6+q-fuX=TFNc3yTLMrbZh17=sLCY2g@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox