| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> |
| Cc: | Antonin Houska <ah(at)cybertec(dot)at>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Treat <rob(at)xzilla(dot)net> |
| Subject: | Re: Adding REPACK [concurrently] |
| Date: | 2026-04-17 14:44:12 |
| Message-ID: | aeJHPNmL4vVy3oPw@pryzbyj2023 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I had trouble testing this at first:
postgres=# REPACK (CONCURRENTLY) users;
ERROR: 42501: permission denied to use replication slots
DETAIL: Only roles with the REPLICATION attribute may use replication slots.
CONTEXT: REPACK decoding worker
LOCATION: CheckSlotPermissions, slot.c:1697
That's surprising, since it was run as a superuser.
It turns out that repack runs as the owner of the table, and the table
*owner* needs to have REPLICATION -- regardless of who runs the command.
I imagine people have been testing with one user, that both owns the
table and invokes REPACK. Maybe this just needs to be clarified in the
documentation/error message?
--
Justin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2026-04-17 14:44:22 | Re: First draft of PG 19 release notes |
| Previous Message | Lucas DRAESCHER | 2026-04-17 14:43:44 | Re: [Bug Report + Patch] File descriptor leak when io_method=io_uring |