Ok, I can't add much to the implementation discussion, but I can confirm the patch resolves both use cases I reported.
Radim On Wed, 30 Sept 2026 at 16:41, Antonin Houska <[email protected]> wrote: > Álvaro Herrera <[email protected]> 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 >
