MIME-Version: 1.0
References: <19519-fe02d8ff679d834d@postgresql.org>
 <CAFC+b6rLNvDzzYxrfLdq7CWbbouHcuOxi-mjEOW1r3qy2uAPMQ@mail.gmail.com>
 <CA+UBfan1QukfNDPvb2YpPG-ME4vUduBfbbe5uWptXDryZbtwVA@mail.gmail.com>
 <aktM919ANQGYZcsj@paquier.xyz>
 <CAEze2WhCRX86ZY2QN7vuGc3wsAyOJbArFSc0i5KtMVnsguA7Kw@mail.gmail.com>
 <akw336Xpi9Ck9-Oz@paquier.xyz>
 <CAEze2WgBjhf6KTKuJ-UqHHGj9Z66f62grmJgZ1EazvMH9HU+XA@mail.gmail.com>
 <akxZiYmGhvNfPVvh@paquier.xyz> <akyM9G67ZIhPXjmQ@paquier.xyz>
In-Reply-To: <akyM9G67ZIhPXjmQ@paquier.xyz>
From: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Date: Tue, 7 Jul 2026 22:40:12 +0530
Message-ID: 
 <CAFC+b6rOdx6rMi_numCrK8cM4z_HWQKrAcBY0dfrRcRWTRpsBQ@mail.gmail.com>
Subject: Re: BUG #19519: REPACK can fail due to missing chunk for toast value
To: Michael Paquier <michael@paquier.xyz>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>,
 Imran Zaheer <imran.zhir@gmail.com>,
	Alexander Lakhin <exclusion@gmail.com>,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
 Konstantin Knizhnik <knizhnik@garret.ru>
Content-Type: multipart/alternative; boundary="00000000000076882f0656087716"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFC%2Bb6rOdx6rMi_numCrK8cM4z_HWQKrAcBY0dfrRcRWTRpsBQ%40mail.gmail.com>
Precedence: bulk

--00000000000076882f0656087716
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Jul 7, 2026 at 10:52=E2=80=AFAM Michael Paquier <michael@paquier.xy=
z> wrote:

>
> Option 2 leads to a much nicer result overall, with the attached
> passing my regression tests and Alexander's case as well (highly
> concurrent thing sent yesterday).  The rest of the patch is kind of
> boring, where I have been trying to get a missing_ok state across the
> stack to let the toast slice fetch bypass the case of missing chunks
> when we are OK with it due to the rewrites.  That still feels crude,
> but the simplicity is appealing here, as much as the rather low
> invasiveness.
>
> Thoughts or comments?


With the initial reproducer, I originally thought this bug was driven
entirely
by a long-running query in another database causing a self-inflicted horizo=
n
drag on the rewrite operation. My theory was that the cross-database sleepe=
r
drags down the global xmin, which infects the snapshot held by VACUUM FULL.
During ComputeXidHorizons, VACUUM FULL ends up dragging its own garbage
collection horizon backward. Lazy vacuum avoids this trap because it
utilizes the
PROC_IN_VACUUM flag to ignore its own snapshot.Since we cannot simply apply
PROC_IN_VACUUM to VACUUM FULL (it needs standard MVCC snapshots to
safely evaluate index expressions), and we can't remove it from lazy vacuum
(which would cause bloat), patching the rewrite operation to explicitly
ignore its
own snapshot during GC calculation (excludeMyself) seemed like the correct
fix.

The script proved that OldestXmin can be dragged backward by other
processes,
bypassing the patch entirely.If a completely separate process in the same
database
(such as a simple \d catalog lookup) requests a global snapshot, it gets
"infected" by
the long-running query in the other database. This new query now sits in
the local ProcArray.
Lazy Vacuum runs, ignores the cross-database sleeper, calculates an
aggressive horizon,
and physically removes the TOAST chunks.VACUUM FULL runs, sees the local
carrier
query, and is forced to respect its older snapshot. Its horizon is dragged
backward, it
assumes the main tuples are RECENTLY_DEAD, attempts to copy them, and
crashes
because the TOAST chunks are gone.

so my initial thoughts are that until there's dependency of
OldestXmin calculation on
global snapshot , the rewrite horizon getting dragged back seems
inevitable, so i think
compared to other approaches in the thread ,your approach of ignoring the
fact of
missing chunks seems good. I quickly reviewed the core logic of treating
the missing
chunks as dead and LGTM will further look into this and test.

--=20
Thanks :)
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 7, 2=
026 at 10:52=E2=80=AFAM Michael Paquier &lt;<a href=3D"mailto:michael@paqui=
er.xyz">michael@paquier.xyz</a>&gt; wrote:</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">
<br>
Option 2 leads to a much nicer result overall, with the attached<br>
passing my regression tests and Alexander&#39;s case as well (highly<br>
concurrent thing sent yesterday).=C2=A0 The rest of the patch is kind of<br=
>
boring, where I have been trying to get a missing_ok state across the<br>
stack to let the toast slice fetch bypass the case of missing chunks<br>
when we are OK with it due to the rewrites.=C2=A0 That still feels crude,<b=
r>
but the simplicity is appealing here, as much as the rather low<br>
invasiveness.<br>
<br>
Thoughts or comments?</blockquote><div><br>With the initial reproducer, I o=
riginally thought this bug was driven entirely<br>by a long-running query i=
n another database causing a self-inflicted horizon<br>drag on the rewrite =
operation. My theory was that the cross-database sleeper<br>drags down the =
global xmin, which infects the snapshot held by VACUUM FULL.<br>During Comp=
uteXidHorizons, VACUUM FULL ends up dragging its own garbage<br>collection =
horizon backward. Lazy vacuum avoids this trap because it utilizes the<br>P=
ROC_IN_VACUUM flag to ignore its own snapshot.Since we cannot simply apply<=
br>PROC_IN_VACUUM to VACUUM FULL (it needs standard MVCC snapshots to<br>sa=
fely evaluate index expressions), and we can&#39;t remove it from lazy vacu=
um<br>(which would cause bloat), patching the rewrite operation to explicit=
ly ignore its<br>own snapshot during GC calculation (excludeMyself) seemed =
like the correct fix.<br><br>The script proved that OldestXmin can be dragg=
ed backward by other processes,<br>bypassing the patch entirely.If a comple=
tely separate process in the same database<br>(such as a simple \d catalog =
lookup) requests a global snapshot, it gets &quot;infected&quot; by<br>the =
long-running query in the other database. This new query now sits in the lo=
cal ProcArray.<br>Lazy Vacuum runs, ignores the cross-database sleeper, cal=
culates an aggressive horizon,<br>and physically removes the TOAST chunks.V=
ACUUM FULL runs, sees the local carrier<br>query, and is forced to respect =
its older snapshot. Its horizon is dragged backward, it<br>assumes the main=
 tuples are RECENTLY_DEAD, attempts to copy them, and crashes<br>because th=
e TOAST chunks are gone.<br><br>so my initial thoughts are that until there=
&#39;s=C2=A0dependency of OldestXmin=C2=A0calculation on<br>global snapshot=
 , the rewrite horizon getting dragged back seems inevitable, so i think<br=
>compared to other=C2=A0approaches in the thread ,your approach of<span sty=
le=3D"background-color:transparent">=C2=A0ignoring=C2=A0the fact of<br>miss=
ing chunks seems good. I quickly reviewed the core logic of treating the mi=
ssing<br>chunks as dead and LGTM will further look into this and test.</spa=
n></div></div><div><br></div><span class=3D"gmail_signature_prefix">-- </sp=
an><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><span st=
yle=3D"color:rgb(34,34,34)">Thanks :)</span><br style=3D"color:rgb(34,34,34=
)"><span style=3D"color:rgb(34,34,34)">Srinath Reddy Sadipiralla</span><br =
style=3D"color:rgb(34,34,34)"><span style=3D"color:rgb(34,34,34)">EDB:=C2=
=A0</span><a href=3D"https://www.enterprisedb.com/" style=3D"color:rgb(17,8=
5,204)" target=3D"_blank">https://www.enterprisedb.com/</a></div></div></di=
v>

--00000000000076882f0656087716--