From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: logrep stuck with 'ERROR: int2vector has too many elements' |
Date: | 2023-01-15 20:48:14 |
Message-ID: | 1691575.1673815694@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> BTW, fd0b9dceb is in v15, so are you sure this doesn't fail in 15?
Ah-hah: simple test cases only fail since b7ae03953. Before
that, the default situation was that pg_publication_rel.prattrs
was null and that would be passed on as the transmitted value.
b7ae03953 decided it'd be cool if pg_get_publication_tables()
expanded that to show all the actually-transmitted columns,
and as of that point we can get an overflow in int2vectorin
given the default case where all columns are published.
To break it in v15, you need a test case that publishes more than
100 columns, but not all of them (else the optimization in
fetch_remote_table_info's query prevents the issue).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-01-15 20:53:09 | Re: logrep stuck with 'ERROR: int2vector has too many elements' |
Previous Message | Andres Freund | 2023-01-15 20:36:31 | Re: logrep stuck with 'ERROR: int2vector has too many elements' |