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

From Antonin Houska
Subject Re: REPACK (CONCURRENTLY) might keep dropped-column data
Date
Msg-id 83138.1790779305@localhost
Whole thread
In response to Re: REPACK (CONCURRENTLY) might keep dropped-column data  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: REPACK (CONCURRENTLY) might keep dropped-column data
List pgsql-hackers
Álvaro Herrera <alvherre@kurilemu.de> wrote:

> 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.

I thought of fixing this on the decoding worker side so that the dropped
attribute values are not even written to the output file. However that would
require one more forming of the tuple.

> 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.

Maybe prepare_concurrent_update(), as it's called right before
apply_concurrent_update()?

BTW, I've noticed now that the 'relation' argument of adjust_toast_pointers()
isn't used anymore. Perhaps it was used before the tuple slots have been
introduced into the function.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com



pgsql-hackers by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: [PATCH] intXshr, intXshl: return error on shift count out of range
Next
From: Nisha Moond
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication