Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
To: Antonin Houska <ah@cybertec.at>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
alvherre@kurilemu.de
Date: 2026-04-17T17:40:39Z
Lists: pgsql-hackers
Hi On Fri, Apr 17, 2026 at 8:45 AM Antonin Houska <ah@cybertec.at> wrote: > 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. > I started with that but tried to follow the existing code pattern. This LGTM. Please add a comment as well. > > -- > Antonin Houska > Web: https://www.cybertec-postgresql.com > >
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
REPACK CONCURRENTLY: fix processing of toasted tuples
- 6ca631b99012 19 (unreleased) landed