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.

1 files changed, 1 insertions, 1 deletions

diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.c
index 824d7572faf..6a0d273bd26 100644
--- a/src/backend/utils/adt/ruleutils.c
+++ b/src/backend/utils/adt/ruleutils.c
@@ -1851,7 +1851,7 @@ pg_get_constraintdef_worker(Oid constraintId, bool fullCommand,
 			heap_close(relation, AccessShareLock);
 			return NULL;
 		}
-		elog(ERROR, "cache lookup failed for constraint %u", constraintId);
+		elog(ERROR, "could not find tuple for constraint %u", constraintId);
 	}
 
 	conForm = (Form_pg_constraint) GETSTRUCT(tup);