From 7f72fd8c47f40b9ebe139a2346a0c234e0703271 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 17 Jul 2004 17:28:29 +0000 Subject: [PATCH] When renaming a column that participates in a foreign key, we must force relcache rebuild for the other table as well as the column's own table. Otherwise, already-cached foreign key triggers will stop working. Per example from Alexander Pravking. --- src/backend/commands/tablecmds.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index a5a7deadcf..d5cdb909c3 100644 --- a/src/backend/commands/tablecmds.c +++ b/src/backend/commands/tablecmds.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/commands/tablecmds.c,v 1.119 2004/07/11 23:13:53 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/commands/tablecmds.c,v 1.120 2004/07/17 17:28:29 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -1706,6 +1706,20 @@ update_ri_trigger_args(Oid relid, CatalogUpdateIndexes(tgrel, tuple); + /* + * Invalidate trigger's relation's relcache entry so that other + * backends (and this one too!) are sent SI message to make them + * rebuild relcache entries. (Ideally this should happen + * automatically...) + * + * We can skip this for triggers on relid itself, since that + * relcache flush will happen anyway due to the table or column + * rename. We just need to catch the far ends of RI relationships. + */ + pg_trigger = (Form_pg_trigger) GETSTRUCT(tuple); + if (pg_trigger->tgrelid != relid) + CacheInvalidateRelcacheByRelid(pg_trigger->tgrelid); + /* free up our scratch memory */ pfree(newtgargs); heap_freetuple(tuple); -- 2.40.0