Re: Adding REPACK [concurrently]

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

In response to

Responses

Browse pgsql-hackers by date

  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