Re: [BUG]Update Toast data failure in logical replication - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [BUG]Update Toast data failure in logical replication
Date
Msg-id CA+Tgmobef7QJYWrvguG3xpck71w-yfTJEMkhPW6n4zyB_V7kJw@mail.gmail.com
Whole thread Raw
In response to Re: [BUG]Update Toast data failure in logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [BUG]Update Toast data failure in logical replication
List pgsql-hackers
On Tue, Aug 10, 2021 at 1:20 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> It seems to me this problem exists from the time we introduced
> wal_level = logical in the commit e55704d8b2 [1], or another
> possibility is that logical replication commit didn't consider
> something to make it work. Andres, Robert, Petr, can you guys please
> comment because otherwise, we might miss something here.

I'm belatedly getting around to looking at this thread. My
recollection of this is:

I think we realized when we were working on the logical decoding stuff
that the key columns of the old tuple would have to be detoasted in
order for the mechanism to work, because I remember worrying about
whether it would potentially be a problem that the WAL record would
end up huge. However, I think we believed that the new tuple wouldn't
need to have the detoasted values, because logical decoding is
designed to notice all the TOAST insertions for the new tuple and
reassemble those separate chunks to get the original value back. And
off-hand I'm not sure why that logic doesn't apply just as much to the
key columns as any others.

But the evidence does suggest that there's some kind of bug here, so
evidently there's some flaw in that line of thinking. I'm not sure
off-hand what it is, though.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Why is src/test/modules/committs/t/002_standby.pl flaky?
Next
From: Robert Haas
Date:
Subject: Re: refactoring basebackup.c