Andres Freund writes:
> WFM, just wanted to be sure we thought about the errors it could cause. I'm
> not sure we've exercised cases of tuples being too wide due to variable-width
> plain storage types exhaustively. There's only a small number of these types:
> int2vector, oidvector, gtsvector,
Hi,
On 2023-01-15 15:53:09 -0500, Tom Lane wrote:
> Andres Freund writes:
> > For the purpose here a limit of MaxTupleAttributeNumber or such instead of
> > FUNC_MAX_ARGS would do the trick, I think?
>
> As long as we have to change the code, we might as well remove the
> arbitrary restriction.
Andres Freund writes:
> For the purpose here a limit of MaxTupleAttributeNumber or such instead of
> FUNC_MAX_ARGS would do the trick, I think?
As long as we have to change the code, we might as well remove the
arbitrary restriction.
> Should this be repalloc0? I don't know if the palloc0 above
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
Hi,
On 2023-01-15 15:17:16 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-01-15 14:39:41 -0500, Tom Lane wrote:
> >> 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
Andres Freund writes:
> On 2023-01-15 14:39:41 -0500, Tom Lane wrote:
>> 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
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,
I wrote:
> Alvaro Herrera 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
Alvaro Herrera writes:
> On 2023-Jan-15, Erik Rijkers wrote:
>> Logical replication sometimes gets stuck with
>> ERROR: int2vector has too many elements
> Weird. This error comes from int2vectorin which amusingly only wants to
> read up to FUNC_MAX_ARGS values in the array (100 in the default
On Sunday, January 15, 2023 5:35 PM Erik Rijkers wrote:
>
> I can't find the exact circumstances that cause it but it has something to do
> with
> many columns (or adding many columns) in combination with perhaps
> generated columns.
>
> This replication test, in a slightly different form,
On 1/15/23 12:33, Alvaro Herrera wrote:
On 2023-Jan-15, Erik Rijkers wrote:
Hello,
Logical replication sometimes gets stuck with
ERROR: int2vector has too many elements
Weird. This error comes from int2vectorin which amusingly only wants to
read up to FUNC_MAX_ARGS values in the array
On 2023-Jan-15, Erik Rijkers wrote:
> Hello,
>
> Logical replication sometimes gets stuck with
> ERROR: int2vector has too many elements
Weird. This error comes from int2vectorin which amusingly only wants to
read up to FUNC_MAX_ARGS values in the array (100 in the default config,
but it
Hello,
Logical replication sometimes gets stuck with
ERROR: int2vector has too many elements
I can't find the exact circumstances that cause it but it has something
to do with many columns (or adding many columns) in combination with
perhaps generated columns.
This replication test, in a
13 matches
Mail list logo
