Re: logrep stuck with 'ERROR: int2vector has too many elements' - Mailing list pgsql-hackers

From Andres Freund
Subject Re: logrep stuck with 'ERROR: int2vector has too many elements'
Date
Msg-id 20230115220627.brdeoyyakl6jpzrq@awork3.anarazel.de
Whole thread Raw
In response to Re: logrep stuck with 'ERROR: int2vector has too many elements'  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: logrep stuck with 'ERROR: int2vector has too many elements'
List pgsql-hackers
Hi,

On 2023-01-15 15:53:09 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> 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.

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, tsquery

What's behind using plain for these types? Is it just because we want to use
it in tables that don't have a toast table (namely pg_index)? Obviously we
can't change the storage in existing releases...


> > Should this be repalloc0? I don't know if the palloc0 above was just used with
> > the goal of initializing the "header" fields, or also to avoid trailing
> > uninitialized bytes?
> 
> I think probably the palloc0 was mostly about belt-and-suspenders
> programming.  But yeah, its only real value is to ensure that all
> the header fields are zero, so I don't think we need repalloc0
> when enlarging.  After we set the array size at the end of the
> loop, it'd be a programming bug to touch any bytes beyond that.

Agreed.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: logrep stuck with 'ERROR: int2vector has too many elements'
Next
From: Tom Lane
Date:
Subject: Re: logrep stuck with 'ERROR: int2vector has too many elements'