pgsql: Clean up treatment of missing default and CHECK-constraint recor

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Clean up treatment of missing default and CHECK-constraint recor
Дата
Msg-id E1lTmn7-000735-3O@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Clean up treatment of missing default and CHECK-constraint records.

Andrew Gierth reported that it's possible to crash the backend if no
pg_attrdef record is found to match an attribute that has atthasdef set.
AttrDefaultFetch warns about this situation, but then leaves behind
a relation tupdesc that has null "adbin" pointer(s), which most places
don't guard against.

We considered promoting the warning to an error, but throwing errors
during relcache load is pretty drastic: it effectively locks one out
of using the relation at all.  What seems better is to leave the
load-time behavior as a warning, but then throw an error in any code
path that wants to use a default and can't find it.  This confines
the error to a subset of INSERT/UPDATE operations on the table, and
in particular will at least allow a pg_dump to succeed.

Also, we should fix AttrDefaultFetch to not leave any null pointers
in the tupdesc, because that just creates an untested bug hazard.

While at it, apply the same philosophy of "warn at load, throw error
only upon use of the known-missing info" to CHECK constraints.
CheckConstraintFetch is very nearly the same logic as AttrDefaultFetch,
but for reasons lost in the mists of time, it was throwing ERROR for
the same cases that AttrDefaultFetch treats as WARNING.  Make the two
functions more nearly alike.

In passing, get rid of potentially-O(N^2) loops in equalTupleDesc
by making AttrDefaultFetch sort the entries after fetching them,
so that equalTupleDesc can assume that entries in two equal tupdescs
must be in matching order.  (CheckConstraintFetch already was sorting
CHECK constraints, but equalTupleDesc hadn't been told about it.)

There's some argument for back-patching this, but with such a small
number of field reports, I'm content to fix it in HEAD.

Discussion: https://postgr.es/m/87pmzaq4gx.fsf@news-spur.riddles.org.uk

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/091e22b2e673e3e8480abd68fbb827c5d6979615

Modified Files
--------------
src/backend/access/common/tupdesc.c  |  68 ++++--------
src/backend/commands/tablecmds.c     |  21 ++--
src/backend/executor/execMain.c      |  11 +-
src/backend/parser/parse_utilcmd.c   |   7 +-
src/backend/rewrite/rewriteHandler.c |  29 +++---
src/backend/utils/cache/relcache.c   | 196 +++++++++++++++++++----------------
6 files changed, 173 insertions(+), 159 deletions(-)


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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: pgsql: Stop archive recovery if WAL generated with wal_level=minimal is
Следующее
От: Peter Geoghegan
Дата:
Сообщение: pgsql: Refactor lazy_scan_heap() loop.