Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
| От | Chao Li |
|---|---|
| Тема | Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY |
| Дата | |
| Msg-id | 98247BB5-5FE5-4F32-A23D-0A3ED808AB19@gmail.com обсуждение |
| Ответ на | [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY (SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>) |
| Список | 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 по дате отправления: