Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY - Mailing list pgsql-hackers

From Chao Li
Subject Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
Date
Msg-id 98247BB5-5FE5-4F32-A23D-0A3ED808AB19@gmail.com
Whole thread
In response to [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY  (SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>)
List pgsql-hackers

> On Apr 16, 2026, at 14:13, SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> wrote:
>
> Hi hackers,
>
> restore_tuple() in repack.c uses SET_VARSIZE() to reconstruct the varlena header when
> reading back external attributes from the spill file. In this process, looks like the flag
> 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
> compressed bytes behind an "uncompressed" header returning garbled data on subsequent reads.
> It appears that existing tests are using random chars which are uncompressable.
>
> Please find the attached 0001-Fix-restore_tuple-losing-varlena-compression-flag.patch to fix this.
> Additionally I updated the existing repack_toast test to include the scenario I was talking about.
>
> Thanks,
> Satya
> <0001-Fix-restore_tuple-losing-varlena-compression-flag.patch><0002-Add-compressed-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’t put
ithere. If somebody is interested in it, then I can provide. 

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

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







pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel Apply
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Fix stats reporting delays in logical parallel apply worker