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

From Tom Lane
Subject Re: logrep stuck with 'ERROR: int2vector has too many elements'
Date
Msg-id 1741603.1673821106@sss.pgh.pa.us
Whole thread Raw
In response to Re: logrep stuck with 'ERROR: int2vector has too many elements'  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> 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, 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...

For int2vector and oidvector, I think it boils down to wanting to access
columns like pg_proc.proargtypes without detoasting.  We could fix that,
but it'd likely be invasive and not a net positive.

It seems a bit broken that tsquery is marked that way, though; I doubt
we are getting any notational benefit from it.

Dunno about gtsvector.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: logrep stuck with 'ERROR: int2vector has too many elements'
Next
From: Justin Pryzby
Date:
Subject: Re: Add LZ4 compression in pg_dump