Re: ALTER TABLE ADD COLUMN fast default

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER TABLE ADD COLUMN fast default
Дата
Msg-id 388298.1617576605@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ALTER TABLE ADD COLUMN fast default  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: ALTER TABLE ADD COLUMN fast default
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 4/4/21 12:05 PM, Tom Lane wrote:
>> I made CheckConstraintFetch likewise not install its array until
>> it's done.  I notice that it is throwing elog(ERROR) not WARNING
>> for the equivalent cases of not finding the right number of
>> entries.  I wonder if we ought to back that off to a WARNING too.
>> elog(ERROR) during relcache entry load is kinda nasty, because
>> it prevents essentially *all* use of the relation.  On the other
>> hand, failing to enforce check constraints isn't lovely either.
>> Anybody have opinions about that?

> None of this is supposed to happen, is it? If you can't fetch the
> constraints (and I think of a default as almost a kind of constraint)
> your database is already somehow corrupted. So maybe if any of these
> things happen we should ERROR out. Anything else seems likely to corrupt
> the database further.

Meh.  "pg_class.relchecks is inconsistent with the number of entries
in pg_constraint" does not seem to me like a scary enough situation
to justify a panic response.  Maybe there's an argument for failing
at the point where we'd need to actually apply the CHECK constraints
(similarly to what my patch is doing for missing defaults).
But preventing the user from, say, dumping the data in the table
seems to me to be making the situation worse not better.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Support for NSS as a libpq TLS backend
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Autovacuum on partitioned table (autoanalyze)