I wrote: > Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: >> At the same time, I don't understand why it fails in 16 but not in 15. >> Maybe something changed in the way we process the column lists in 16?
> Probably didn't have a dependency on int2vector before. It looks like the proximate cause is that fd0b9dceb started fetching the remote's pg_get_publication_tables() result as-is rather than unnesting it, so that the on-the-wire representation is now int2vector not a series of int2. However, that just begs the question of who thought that making pg_publication_rel.prattrs be int2vector instead of int2[] was a good idea. Quite aside from this issue, int2vector isn't toastable, which'll lead to bloat in pg_publication_rel. But I suppose we are stuck with that, seeing that this datatype choice is effectively part of the logrep protocol now. I think the only reasonable solution is to get rid of the FUNC_MAX_ARGS restriction in int2vectorin. We probably ought to back-patch that as far as pg_publication_rel.prattrs exists, too. BTW, fd0b9dceb is in v15, so are you sure this doesn't fail in 15? It looks like the code path is only taken if the remote is also >= 15, so maybe your test case didn't expose it? regards, tom lane