From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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 22:18:26 |
Message-ID: | 1741603.1673821106@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2023-01-15 22:32:11 | Re: Add LZ4 compression in pg_dump |
Previous Message | Andres Freund | 2023-01-15 22:06:27 | Re: logrep stuck with 'ERROR: int2vector has too many elements' |