Re: REPACK (CONCURRENTLY) might keep dropped-column data

From: Antonin Houska <ah(at)cybertec(dot)at>
To: alvherre(at)kurilemu(dot)de
Cc: Radim Marek <radim(at)boringsql(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: REPACK (CONCURRENTLY) might keep dropped-column data
Date: 2026-09-30 14:41:45
Message-ID: 83138.1790779305@localhost
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Álvaro Herrera <alvherre(at)kurilemu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nisha Moond 2026-09-30 14:45:35 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Pavel Borisov 2026-09-30 14:28:12 Re: [PATCH] intXshr, intXshl: return error on shift count out of range