From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Overflow of attmissingval is not handled gracefully |
Date: | 2022-02-28 23:46:49 |
Message-ID: | 2752049.1646092009@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 2/28/22 18:21, Tom Lane wrote:
>> regression=# create table foo(f1 int);
>> CREATE TABLE
>> regression=# alter table foo add column bar text default repeat('xyzzy', 1000000);
>> ERROR: row is too big: size 57416, maximum size 8160
>>
>> I think the simplest answer, and likely the only feasible one for
>> the back branches, is to disable the attmissingval optimization
>> if the proposed value is "too large". Not sure exactly where the
>> threshold for that ought to be, but maybe BLCKSZ/8 could be a
>> starting offer.
> WFM. After all, it's taken several years for this to surface. Is it
> based on actual field experience?
No, it was an experiment that occurred to me while thinking about
the nearby proposal to add a TOAST table to pg_attribute [1].
If we do that, this restriction could be dropped. But I agree that
there's hardly any practical use-case for such default values,
so I wouldn't mind living with the de-optimization either.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/1643112264(dot)186902312(at)f325(dot)i(dot)mail(dot)ru
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2022-03-01 00:07:28 | Re: Allow root ownership of client certificate key |
Previous Message | Andrew Dunstan | 2022-02-28 23:36:14 | Re: Overflow of attmissingval is not handled gracefully |