I wrote:
> Alvaro Herrera <alvherre@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