agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
Date: Tue, 17 Mar 2026 20:57:06 +0100
Message-ID: <91049.1773777426@localhost> (raw)
In-Reply-To: <9548.1773744820@localhost>
References: <202603162202.l2sibdzviih7@alvherre.pgsql>
<9548.1773744820@localhost>
Antonin Houska <ah@cybertec.at> wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> > On 2026-Mar-16, Matthias van de Meent wrote:
> >
> > > On Mon, 16 Mar 2026 at 21:15, Antonin Houska <ah@cybertec.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 ...
>
> Admittedly, it is a problem. I tried to address this in pg_squeeze by
> pre-allocating slots when it's clear (due to scheduling) that more than one
> table needs to be processed. This was an effort to achieve the best possible
> performance rather than a response to complaints of users about low
> throughput. Nevertheless, I'm glad I happened to mention it before it's too
> late.
>
> Regarding solution, a flag like SAFE_IN_IC alone does not help. The
> information that particular transaction is used by REPACK (and therefore it
> does not have to be decoded) would need to be propagated to the
> xl_running_xacts WAL record too.
0007 in the next version tries to implement that.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Attachments:
[text/x-diff] v42-0001-Refactor-index_concurrently_create_copy-for-use-with.patch (0B, ../91049.1773777426@localhost/2-v42-0001-Refactor-index_concurrently_create_copy-for-use-with.patch)
download
view thread (416+ messages) latest in thread
Message-ID: <91049.1773777426@localhost>
Permalink: ../91049.1773777426@localhost/
Also on: postgresql.org/message-id/91049.1773777426@localhost
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: pgsql-hackers@postgresql.org
Cc: ah@cybertec.at, alvherre@alvh.no-ip.org, boekewurm+postgres@gmail.com, mihailnikalayeu@gmail.com, pgsql-hackers@lists.postgresql.org, rob@xzilla.net
Subject: Re: Adding REPACK [concurrently]
In-Reply-To: <91049.1773777426@localhost>
* 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