Replace over-optimistic Assert in partitioning code with a runtime test.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 4 Jun 2017 20:20:03 +0000 (16:20 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 4 Jun 2017 20:20:03 +0000 (16:20 -0400)
commite7941a976688f0f5d13a5227ed4f3efe0718db9d
tree70ed212430cbfe514222fb70d8b8115fd695b316
parent9db7d47f909482ac2b76c28f5e9a2ef48fb19b9d
Replace over-optimistic Assert in partitioning code with a runtime test.

get_partition_parent felt that it could simply Assert that systable_getnext
found a tuple.  This is unlike any other caller of that function, and it's
unsafe IMO --- in fact, the reason I noticed it was that the Assert failed.
(OK, I was working with known-inconsistent catalog contents, but I wasn't
expecting the DB to fall over quite that violently.  The behavior in a
non-assert-enabled build wouldn't be very nice, either.)  Fix it to do what
other callers do, namely an actual runtime-test-and-elog.

Also, standardize the wording of elog messages that are complaining about
unexpected failure of systable_getnext.  90% of them say "could not find
tuple for <object>", so make the remainder do likewise.  Many of the
holdouts were using the phrasing "cache lookup failed", which is outright
misleading since no catcache search is involved.
contrib/sepgsql/database.c
contrib/sepgsql/proc.c
contrib/sepgsql/relation.c
contrib/sepgsql/schema.c
src/backend/catalog/aclchk.c
src/backend/catalog/objectaddress.c
src/backend/catalog/partition.c
src/backend/commands/extension.c
src/backend/utils/adt/ruleutils.c