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>
In-Reply-To: <88003.1769511456@localhost>
From: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Date: Wed, 28 Jan 2026 03:06:00 +0100
Message-ID: <CADzfLwXdaJh4awQstc2PpBz=EBBc6tMA50wYLqMoEtY5B+WUnA@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="000000000000c91245064969315b"
Archived-At: <https://www.postgresql.org/message-id/CADzfLwXdaJh4awQstc2PpBz%3DEBBc6tMA50wYLqMoEtY5B%2BWUnA%40mail.gmail.com>
Precedence: bulk

--000000000000c91245064969315b
Content-Type: text/plain; charset="UTF-8"

Hello!

> PROC_IN_VACUUM shouldn't be used for the same reason
StartupDecodingContext()
>  avoids setting PROC_IN_LOGICAL_DECODING in transaction. I've removed
that and
>  the tests work for me. Especially the "cache lookup failed" error is
almost
>  certainly related. Please let me know if you still get the other errors

Yes, now it is passing.

>  (Except for 2, which is probably due to the MVCC-unsafe behavior, as
discussed
>  earlier.)

Not happening too. BTW, it was non MVCC-related, because in that case
relcheckxmin would catch it.

What if:

1) add new PROC_IN_REPACK flag
2) use it in catalog horizon, but not in data (like was done in [0] for
PROC_IN_SAFE_IC)

And after we have options:
    3) do not "table_close(NewHeap, NoLock);" -
keep ShareUpdateExclusiveLock all the time to prevent VACUUM enter
    4) do not heap_page_prune_opt in repack transaction (just using simple
flag)
Or
    3) preserve xmin/xmax of original transaction in repacked data
    4) but better to keep ShareUpdateExclusiveLock anyway

Seems to be enough.

> The 0006 part needs more work (definitely beyond PG 19).

This is sad, because if you are in a situation then you need REPACK -
pinning the horizon for too long may just finish your DB....
And also, even with 0006 we still need to build indexes, which might pin it
for long (even duration caused by a single index).

Mikhail.

[0]:
https://github.com/postgres/postgres/commit/d9d076222f5b94a85e0e318339cfc44b8f26022d

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

<div dir=3D"ltr"><div>Hello!</div><div><br></div><div>&gt; PROC_IN_VACUUM s=
houldn&#39;t be used for the same reason StartupDecodingContext()<br>&gt;=
=C2=A0 avoids setting PROC_IN_LOGICAL_DECODING in transaction. I&#39;ve rem=
oved that and<br>&gt;=C2=A0 the tests work for me. Especially the &quot;cac=
he lookup failed&quot; error is almost<br>&gt;=C2=A0 certainly related. Ple=
ase let me know if you still get the other errors<br></div><div><br></div><=
div>Yes, now it is passing.</div><div><br></div><div>&gt;=C2=A0 (Except for=
 2, which is probably due to the MVCC-unsafe behavior, as discussed<br>&gt;=
=C2=A0 earlier.)</div><div><br></div><div>Not happening too. BTW, it was no=
n MVCC-related, because in that case relcheckxmin would catch it.</div><div=
><br></div><div>What if:</div><div><br></div><div>1) add new PROC_IN_REPACK=
 flag</div><div>2) use it in catalog horizon, but not in data (like was don=
e in [0] for PROC_IN_SAFE_IC)</div><div><br></div><div>And after we have op=
tions:</div><div>=C2=A0 =C2=A0 3) do not &quot;table_close(NewHeap, NoLock)=
;&quot; - keep=C2=A0ShareUpdateExclusiveLock all the time to prevent VACUUM=
 enter</div><div>=C2=A0 =C2=A0 4) do not heap_page_prune_opt in repack tran=
saction (just using simple flag)</div><div>Or</div><div>=C2=A0 =C2=A0 3) pr=
eserve xmin/xmax of original transaction in repacked data</div><div>=C2=A0 =
=C2=A0 4) but better to keep ShareUpdateExclusiveLock anyway</div><div><br>=
</div><div>Seems to be enough.</div><div><br></div><div>&gt; The 0006 part =
needs more work (definitely beyond PG 19).</div><div><br></div><div>This is=
 sad, because if you are in a situation then you need REPACK - pinning the =
horizon for too long may just finish your DB....</div><div>And also, even=
=C2=A0with 0006 we still need to build indexes,=C2=A0which might pin it for=
 long (even duration caused by a single index).</div><div><br></div><div>Mi=
khail.</div><div><br></div><div>[0]:=C2=A0<a href=3D"https://github.com/pos=
tgres/postgres/commit/d9d076222f5b94a85e0e318339cfc44b8f26022d">https://git=
hub.com/postgres/postgres/commit/d9d076222f5b94a85e0e318339cfc44b8f26022d</=
a></div></div>

--000000000000c91245064969315b--