aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeHashjoin.c
diff options
context:
space:
mode:
authorAlvaro Herrera <alvherre@alvh.no-ip.org>2019-01-21 19:34:11 -0300
committerAlvaro Herrera <alvherre@alvh.no-ip.org>2019-01-21 19:34:11 -0300
commit3037b28b89b44fccfcfddb2254655f45b3005f82 (patch)
tree41b430f43c341ff193d06b8bcaa807b21870ed35 /src/backend/executor/nodeHashjoin.c
parentc2f557d4fa93664855a4e0a9cebe0c73d9998b84 (diff)
downloadpostgresql-3037b28b89b44fccfcfddb2254655f45b3005f82.tar.gz
postgresql-3037b28b89b44fccfcfddb2254655f45b3005f82.zip
Flush relcache entries when their FKs are meddled with
Back in commit 100340e2dcd0, we made relcache entries keep lists of the foreign keys applying to the relation -- but we forgot to update CacheInvalidateHeapTuple to flush those entries when new FKs got created or existing ones updated/deleted. No bugs appear to have been reported that would be explained by this ommission, but I noticed the problem while working on an unrelated bugfix which clearly showed it. Fix by adding relcache flush on relevant foreign key changes. Backpatch to 9.6, like the aforementioned commit. Discussion: https://postgr.es/m/201901211927.7mmhschxlejh@alvherre.pgsql Reviewed-by: Tom Lane
Diffstat (limited to 'src/backend/executor/nodeHashjoin.c')
0 files changed, 0 insertions, 0 deletions