Hi, On 2022-01-24 15:10:05 -0500, Robert Haas wrote: > 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.
Possibly the root of the problem is that we/I didn't think of cases where the primary key is an external toast datum - in moast scenarios you'd an error about a too wide index tuple. But of course that neglects cases where toasting happens due to SET STORAGE or due to the aggregate tuple width, rather than individual column width. > And off-hand I'm not sure why that logic doesn't apply just as much to the > key columns as any others. The difference is that it's mostly fine to not have unchanging key columns as part of decoded update - you just don't update those columns. But you can't do that without knowing the replica identity... Greetings, Andres Freund
