| From: | Antonin Houska <ah(at)cybertec(dot)at> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net> |
| Subject: | Re: Adding REPACK [concurrently] |
| Date: | 2026-03-16 20:15:14 |
| Message-ID: | 107398.1773692114@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. If
non-SUPERUSER user could install C-functions, it'd be easy to install code
that leaks data. 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.
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.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-03-16 20:51:09 | Re: pg_plan_advice |
| Previous Message | Corey Huinker | 2026-03-16 20:04:23 | Re: Add starelid, attnum to pg_stats and leverage this in pg_dump |