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

From Antonin Houska
Subject Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
Date
Msg-id 52301.1776440752@localhost
Whole thread
In response to [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY  (SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>)
Responses Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
List 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


Attachment

pgsql-hackers by date:

Previous
From: Nikolay Samokhvalov
Date:
Subject: xact_rollback spikes when logical walsender exits
Next
From: Maxym Kharchenko
Date:
Subject: Re: Truncate logs by max_log_size