From: Antonin Houska <ah@cybertec.at>
To: alvherre@kurilemu.de
cc: Radim Marek <radim@boringsql.com>,
    PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: REPACK (CONCURRENTLY) might keep dropped-column data
In-reply-to: <arz09-sHiSl3qBN0@alvherre.pgsql>
References: <arz09-sHiSl3qBN0@alvherre.pgsql>
Comments: In-reply-to =?us-ascii?Q?=3D=3Futf-8=3FQ=3F=3DC3=3D81lvaro=3F=3D?=
 Herrera <alvherre@kurilemu.de>
   message dated "Wed, 30 Sep 2026 13:48:05 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Wed, 30 Sep 2026 16:41:45 +0200
Message-ID: <83138.1790779305@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/83138.1790779305%40localhost>
Precedence: bulk

=C3=81lvaro Herrera <alvherre@kurilemu.de> wrote:

> Hello Radim, thanks for testing!
>=20
> On 2026-Sep-30, Radim Marek wrote:
>=20
> > 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.
>=20
> 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.

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