From: Antonin Houska <ah@cybertec.at>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <CADzfLwVf6jB5QBXR3nM838LV6oyqAGJ5b5tXc5aZdovxHPj_kg@mail.gmail.com>
References: <202512151349.vlq3mpfniyk3@alvherre.pgsql> <11247.1767609087@localhost> <11558.1767609632@localhost> <141054.1767891540@localhost> <CADzfLwU-OmxW3t3AoQo9=K7uq4G1yZ-txcetzW3jbcVxV_pJew@mail.gmail.com> <137668.1768235610@localhost> <CADzfLwUJSHKGxYw+vMUZ_Hr2YeuxO2Q5w13HKgUUN1725tjY5Q@mail.gmail.com> <CADzfLwXJ+4s1tJuG9injcxAUP3urj9D6dUAPOCaX33UeiUxrRQ@mail.gmail.com> <74802.1769071060@localhost> <CADzfLwVZ_DeU_3avD=G4ZHFJJgZ0EOFzxnmWxwyB23zsS-uxjA@mail.gmail.com> <CADzfLwUEH5+LjCN+6kRfSsXwuou8rKXyVV42Wi-O_TG0360Kug@mail.gmail.com> <3901.1769412880@localhost> <88003.1769511456@localhost> <CADzfLwXdaJh4awQstc2PpBz=EBBc6tMA50wYLqMoEtY5B+WUnA@mail.gmail.com> <57210.1769801636@localhost> <CADzfLwUukiGOPoUkDgf6oEB-Y0TnNy6UFUN4obnU-AN5W1N=sw@mail.gmail.com> <8029.1770024929@localhost> <CADzfLwVf6jB5QBXR3nM838LV6oyqAGJ5b5tXc5aZdovxHPj_kg@mail.gmail.com>
Comments: In-reply-to Mihail Nikalayeu <mihailnikalayeu@gmail.com>
   message dated "Mon, 02 Feb 2026 11:04:45 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <58249.1770061199.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 02 Feb 2026 20:39:59 +0100
Message-ID: <58250.1770061199@localhost>
Archived-At: <https://www.postgresql.org/message-id/58250.1770061199%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> > I think it *is* related. My earlier patch version, which used the
> > PROC_IN_VACUUM flag improperly [1] was also causing visibility issues.=
  Please
> > let me know if you manage to reproduce the issue with v32.
> =

> Will try. Just to highlight - first error happened on v31 *without* PROC=
_IN_REPACK.
> Second error had PROC_IN_REPACK code, but it wasn't executed (flag wasn'=
t set) - that's why I think it is not related.

ok, v31 is the one that uses PROC_IN_VACUUM incorrectly.

> > I'm confused by hearing a complaint about complexity of code that I ha=
ven't
> > posted yet. And I don't understand the relationship to "replication lo=
gic":
> > REPACK (CONCURRENTLY) tries to avoid decoding of data changes in the *=
new*
> > (transient) relation anyway.
> =

> I am not about complexity of code, but more about complexity of approach=
 (introducing new things like cache-only relations).
> "Replication logic" - is about the fact you mentioned that such a relati=
on is going to be replicated to standby (as result, some
> replication-related code is affected too, probably standby promotion als=
o).

I thought you mean logical replication. Regarding streaming replication, I
mentioned it rather for the record. I need to check details to see if it
requires special attention.

> Compared to the PROC_IN_REPACK flag - it feels overly complicated for me=
.
> PROC_IN_REPACK is the simplest thing here - just exclude XID from data-h=
orizon, but keep it in catalog. That's all.

My preference is to avoid hacking procarray.c if a reasonable alternative
exists.

> Also, maybe I sound a little bit rude, sorry, it is just because of the =
language barrier.

No, that's fine. Since we've met at pgconf.eu, I think you're not a bad gu=
y
:-) Technical discussions are mostly about problems, so they tend to sound
negative as such.

-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com