From 3998d0fdca75dda6bdb0e7bf482746c3f131724d Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 17 Jul 2004 17:28:47 +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 b77faed0d3e..2c3a3760f2f 100644 --- a/src/backend/commands/tablecmds.c +++ b/src/backend/commands/tablecmds.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $Header: /cvsroot/pgsql/src/backend/commands/tablecmds.c,v 1.91 2003/10/13 22:47:15 momjian Exp $ + * $Header: /cvsroot/pgsql/src/backend/commands/tablecmds.c,v 1.91.2.1 2004/07/17 17:28:47 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -1534,6 +1534,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) + CacheInvalidateRelcache(pg_trigger->tgrelid); + /* free up our scratch memory */ pfree(newtgargs); heap_freetuple(tuple);