On 4/4/21 6:50 PM, Tom Lane wrote: > Andrew Dunstan <and...@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. > >
OK, fair argument. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
