MIME-Version: 1.0
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>
In-Reply-To: <8029.1770024929@localhost>
From: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Date: Mon, 2 Feb 2026 11:04:45 +0100
Message-ID: <CADzfLwVf6jB5QBXR3nM838LV6oyqAGJ5b5tXc5aZdovxHPj_kg@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: Antonin Houska <ah@cybertec.at>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, 
	Pg Hackers <pgsql-hackers@lists.postgresql.org>, Robert Treat <rob@xzilla.net>
Content-Type: multipart/alternative; boundary="00000000000022ddbc0649d476e4"
Archived-At: <https://www.postgresql.org/message-id/CADzfLwVf6jB5QBXR3nM838LV6oyqAGJ5b5tXc5aZdovxHPj_kg%40mail.gmail.com>
Precedence: bulk

--00000000000022ddbc0649d476e4
Content-Type: text/plain; charset="UTF-8"

Hello!


> 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.

> I'm confused by hearing a complaint about complexity of code that I
haven't
> posted yet. And I don't understand the relationship to "replication
logic":
> 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 relation
is going to be replicated to standby (as result, some replication-related
code is affected too, probably standby promotion also).

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-horizon, but keep it in catalog. That's all.

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

> 3) XID assigned early due to creation of catalog entries for the new
table -
> that XID prevents the VACUUM xmin horizon from advancing till the end of
the
> transaction, i.e. till the end of REPACK execution.

Yes, but PROC_IN_REPACK covers it as well. That xid only in the catalog
horizon.

> IMO it's better for users to see the correct data than ERROR. But it still
> needs work.
Agreed, for me it is ordered like this (from bad to good):

1) silently see incorrect data in rear race
2) receive error instead in that race    <----- acceptable for me
3) no error, data is correct

Best regards,
Mikhail.

--00000000000022ddbc0649d476e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello!</div><div><br></div><div><br></div><div>&gt; I=
 think it *is* related. My earlier patch version, which used the<br>&gt; PR=
OC_IN_VACUUM flag improperly [1] was also causing visibility issues.=C2=A0 =
Please<br>&gt; let me know if you manage to reproduce the issue with v32.</=
div><div><br></div><div>Will try. Just to highlight - first error happened =
on v31 *without* PROC_IN_REPACK.</div><div>Second error had=C2=A0PROC_IN_RE=
PACK code, but it wasn&#39;t executed (flag wasn&#39;t set) - that&#39;s wh=
y I think it is not related.</div><div><br></div><div>&gt; I&#39;m confused=
 by hearing a complaint about complexity of code that I haven&#39;t<br>&gt;=
 posted yet. And I don&#39;t understand the relationship to &quot;replicati=
on logic&quot;:<br>&gt; REPACK (CONCURRENTLY) tries to avoid decoding of da=
ta changes in the *new*<br>&gt; (transient) relation anyway.</div><div><br>=
</div><div>I am not about complexity of code, but more about complexity of =
approach (introducing new things like cache-only relations).</div><div>&quo=
t;Replication logic&quot; - is about the fact you mentioned that such a rel=
ation is going to be replicated to standby (as result, some replication-rel=
ated code is affected too, probably standby promotion also).</div><div><br>=
</div><div>Compared to the PROC_IN_REPACK flag - it feels overly complicate=
d for me.</div><div>PROC_IN_REPACK is the simplest thing here - just exclud=
e XID from data-horizon, but keep it in catalog. That&#39;s all.</div><div>=
<br></div><div>Also, maybe I sound a little bit rude, sorry, it is just bec=
ause of the language barrier.</div><div><br></div><div>&gt; 3) XID assigned=
 early due to creation of catalog entries for the new table -<br>&gt; that =
XID prevents the VACUUM xmin horizon from advancing till the end of the<br>=
&gt; transaction, i.e. till the end of REPACK execution.</div><div><br></di=
v><div>Yes, but=C2=A0PROC_IN_REPACK covers it as well. That xid only in the=
 catalog horizon.</div><div><br></div><div>&gt; IMO it&#39;s better for use=
rs to see the correct data than ERROR. But it still<br>&gt; needs work.</di=
v><div>Agreed, for me it is ordered like this (from bad to good):</div><div=
><br></div><div>1) silently see incorrect data in rear race</div><div>2) re=
ceive error instead in that race=C2=A0 =C2=A0 &lt;----- acceptable for me</=
div><div>3) no error, data is correct</div><div><br></div><div>Best regards=
,</div><div>Mikhail.</div><div><br></div></div>

--00000000000022ddbc0649d476e4--