aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeCustom.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-06-04 16:20:03 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2017-06-04 16:20:03 -0400
commite7941a976688f0f5d13a5227ed4f3efe0718db9d (patch)
tree70ed212430cbfe514222fb70d8b8115fd695b316 /src/backend/executor/nodeCustom.c
parent9db7d47f909482ac2b76c28f5e9a2ef48fb19b9d (diff)
downloadpostgresql-e7941a976688f0f5d13a5227ed4f3efe0718db9d.tar.gz
postgresql-e7941a976688f0f5d13a5227ed4f3efe0718db9d.zip
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.
Diffstat (limited to 'src/backend/executor/nodeCustom.c')
0 files changed, 0 insertions, 0 deletions