Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CAHg+QDeXb9HM2VGKXQedyCp52GzajJK5KOUdNi6oLjsS0nerQw@mail.gmail.com>
Date: Fri, 17 Apr 2026 17:17:15 +0800
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 =?utf-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>,
 ah@cybertec.at
Content-Transfer-Encoding: quoted-printable
Message-Id: <98247BB5-5FE5-4F32-A23D-0A3ED808AB19@gmail.com>
References: 
 <CAHg+QDeXb9HM2VGKXQedyCp52GzajJK5KOUdNi6oLjsS0nerQw@mail.gmail.com>
To: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/98247BB5-5FE5-4F32-A23D-0A3ED808AB19%40gmail.com>
Precedence: bulk


> On Apr 16, 2026, at 14:13, SATYANARAYANA NARLAPURAM =
<satyanarlapuram@gmail.com> wrote:
>=20
> Hi hackers,
>=20
> restore_tuple() in repack.c uses SET_VARSIZE() to reconstruct the =
varlena header when=20
> reading back external attributes from the spill file. In this process, =
looks like the flag=20
> SET_VARSIZE_COMPRESSED is silently lost. Because of this, when REPACK =
CONCURRENTLY
> run  any concurrently updated column whose value was TOAST-compressed =
ends up with raw=20
> compressed bytes behind an "uncompressed" header returning garbled =
data on subsequent reads.
> It appears that existing tests are using random chars which are =
uncompressable.
>=20
> Please find the attached =
0001-Fix-restore_tuple-losing-varlena-compression-flag.patch to fix =
this.=20
> Additionally I updated the existing repack_toast test to include the =
scenario I was talking about.
>=20
> Thanks,
> Satya
> =
<0001-Fix-restore_tuple-losing-varlena-compression-flag.patch><0002-Add-co=
mpressed-TOAST-test-to-repack_toast.patch>

I managed to reproduce the bug manually, and confirmed your fix to work =
for me. The repro is not simple, so I won=E2=80=99t put it here. If =
somebody is interested in it, then I can provide.

I didn=E2=80=99t review the test in 0002, I guess we don=E2=80=99t have =
to add the test because once fixed, the bug won=E2=80=99t be there =
anymore, thus it=E2=80=99s not worthy extending the test time.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/