| 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: | Whole Thread | Raw Message | 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' |