On Mon, Jan 24, 2022 at 4:17 PM Andres Freund <and...@anarazel.de> wrote: > 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.
That seems consistent with what's been described on this thread so far, but I still don't quite understand why the logic that reassembles TOAST chunks doesn't solve it. I mean, decoding doesn't know whether any changes are happening on the subscriber side, so it's not like we can (a) query for the row and then (b) decide to reassemble TOAST chunks if we find it, or something like that. The decoding has to say, well, here's the new tuple and the old key columns, and then the subscriber does whatever it does. I guess it could check whether the old and new values are identical to decide whether to drop that column out of the result, but it shouldn't compare a TOAST pointer to a detoasted value and go "yeah, that looks equal".... -- Robert Haas EDB: http://www.enterprisedb.com
