| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Antonin Houska <ah(at)cybertec(dot)at>, 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 22:03:04 |
| Message-ID: | 202603162202.l2sibdzviih7@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-Mar-16, Matthias van de Meent wrote:
> On Mon, 16 Mar 2026 at 21:15, Antonin Houska <ah(at)cybertec(dot)at> wrote:
> > 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).
Yeah, this sounds kind of bad news ...
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Los dioses no protegen a los insensatos. Éstos reciben protección de
otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2026-03-16 22:10:17 | Re: A stack allocation API |
| Previous Message | Heikki Linnakangas | 2026-03-16 21:56:23 | Re: Better shared data structure management and resizable shared data structures |