Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
| От | Antonin Houska |
|---|---|
| Тема | Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY |
| Дата | |
| Msg-id | 52301.1776440752@localhost обсуждение |
| Ответ на | [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY (SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>) |
| Ответы |
Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
|
| Список | pgsql-hackers |
SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> wrote: > 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. Good catch, thanks! I'd slightly prefer to fix it w/o checking the varlena type, as attached. However, your test fails to reproduce the issue here, so I'm not able to verify the fix. I'll take a closer look early next week. -- Antonin Houska Web: https://www.cybertec-postgresql.com
Вложения
В списке pgsql-hackers по дате отправления: