Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY

From: Antonin Houska <ah(at)cybertec(dot)at>
To: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, alvherre(at)kurilemu(dot)de
Subject: Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
Date: 2026-04-17 15:45:52
Message-ID: 52301.1776440752@localhost
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)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 Content-Type Size
fix_restore_tuple.diff text/x-diff 576 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Maxym Kharchenko 2026-04-17 17:03:49 Re: Truncate logs by max_log_size
Previous Message Nikolay Samokhvalov 2026-04-17 15:15:00 xact_rollback spikes when logical walsender exits