Re: REPACK (CONCURRENTLY) might keep dropped-column data - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: REPACK (CONCURRENTLY) might keep dropped-column data
Date
Msg-id arz09-sHiSl3qBN0@alvherre.pgsql
Whole thread
In response to Re: REPACK (CONCURRENTLY) might keep dropped-column data  (Radim Marek <radim@boringsql.com>)
Responses Re: REPACK (CONCURRENTLY) might keep dropped-column data
List pgsql-hackers
Hello Radim, thanks for testing!

On 2026-Sep-30, Radim Marek wrote:

> Aha, so on my way to office I started thinking and got more silly ideas,
> and now can confirm this is more widespread than logical subscriber use
> case.

Oh, thanks for the simplified test case.  We can fix this easily by
setting the column to null in the tuple to write out, as in the attached
patch.  The adjust_toast_pointers() function should perhaps be renamed,
and the comment rewritten, since it's no longer just about toast ...
I didn't do that though.

I put together a crude test case to verify with isolationtester.
Without the fix, this reproduces the bloat you saw; with the fix, the
toast table's size after the repack is zero.  This needs some more
boiling before being committable, but it suffices to show the problem.

Regards

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)

Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [PATCH] Two remaining shmem attachment issues in single-user mode
Next
From: Álvaro Herrera
Date:
Subject: Re: [PATCH v1] Fix out-of-bounds access in pg_bsd_indent's parser stack