Hi,
On 2023-01-15 14:39:41 -0500, Tom Lane wrote:
> 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.
There's no easily visible comments about these restrictions of int2vector. And
there's plenty other places using it, where it's not immediatelly obvious that
the number of entries is very constrained, even if they are
(e.g. pg_trigger.tgattr).
> 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.
Are you thinking of introducing another, or just "rely" on too long arrays to
trigger errors when forming tuples?
I guess we'll have to process the input twice? Pre-allocating an int2vector
for 100 elements is one thing, for 1600 another.
Greetings,
Andres Freund