public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: Antonin Houska <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Mihail Nikalayeu <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Robert Treat <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Wed, 1 Apr 2026 14:12:22 +0530
Message-ID: <CAA4eK1L58pxsOPoFD7+4CaNXTfkKJz7x_ZiS4nskMUq8FsEsGA@mail.gmail.com> (raw)
In-Reply-To: <228982.1774967782@localhost>
References: <90700.1774627975@localhost>
<[email protected]>
<CAA4eK1++8RmH9PaFMQCahZQ-PfE5DN0vrCsa4_rSQ6G877Lj3w@mail.gmail.com>
<228982.1774967782@localhost>
On Tue, Mar 31, 2026 at 8:06 PM Antonin Houska <[email protected]> wrote:
>
> Amit Kapila <[email protected]> wrote:
> > 2.
> > *
> > + /*
> > + * TODO Consider a GUC to reserve certain amount of replication slots for
> > + * REPACK (CONCURRENTLY) and using it here.
> > + */
> > +#define MAX_REPACK_XIDS 16
> > +
> >
> > This sounds a bit scary as reserving replication slots for REPACK
> > (CONCURRENTLY) may not be what users expect. But it is not clear why
> > replication slots need to be reserved for this.
>
> The point is that REPACK should not block replication [1]. Thus reserving
> slots for non-REPACK users is probably more precise statement.
>
oh, so shouldn't be a separate patch than this and an important for
this functionality to get committed? I don't see why we need to make
such a GUC or knob as part of this patch if we need the same.
> > IIUC, two reasons why logical decoding can ignore REPACK
> > (CONCURRENTLY) are (a) does not perform any catalog changes relevant
> > to logical decoding, (b) neither walsenders nor backends performing
> > logical decoding needs to care sending the WAL generated by REPACK
> > (CONCURRENTLY). Is that understanding correct? If so, we may want to
> > clarify why we want to ignore this command's WAL while sending changes
> > downstream in the commit message or give some reference of the patch
> > where the same is mentioned. This can help reviewing this patch
> > independently.
>
> Correct, but in fact this diff only affects the setup of the logical decoding
> rather than the decoding itself. On the other hand, if REPACK (CONCURRENTLY)
> starts when the decoding backend's snapshot builder is already in the
> SNAPBUILD_FULL_SNAPSHOT state, reorderbuffer.c processes the transaction
> normally, and another part of the series (v46-0002) ensures that the table
> rewriting is not decoded: REPACK simply tells heap_insert(), heap_update(),
> heap_delete() not to put the extra (replication specific) information into the
> corresponding WAL records. I suppose this is what you mean in (b).
>
> Regarding (a), yes, the absence of catalog changes in the REPACK's transaction
> is the reason that even the logical decoding setup does not have to wait for
> the transaction to finish.
>
Hmm, but we don't do any catalog changes for transactions that have
DML say only INSERT but we don't have separate logic like REPACK in
snapbuild machinery. Same is probably true for dml operations on an
unlogged table which doesn't have WAL to send nor any catalog
operations involved but we don't have any special path for that in
snapbuild code path. So, why do we need special handling for this
operation?
--
With Regards,
Amit Kapila.
view thread (19+ messages) latest in thread
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Adding REPACK [concurrently]
In-Reply-To: <CAA4eK1L58pxsOPoFD7+4CaNXTfkKJz7x_ZiS4nskMUq8FsEsGA@mail.gmail.com>
* 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