ts=# CREATE INDEX ON t(i) ; CREATE INDEX ts=# DROP INDEX t_i_idx ; NOTICE: 00000: drop_trigger LOCATION: exec_stmt_raise, pl_exec.c:3748 DROP INDEX ts=#
ts=# \d t Table "public.t" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- i | integer | | | ts=# SELECT COUNT(1) FROM pg_trigger WHERE tgrelid='t'::regclass; count | 0 It's not specific to the index name, since it can happen multiple times for each index on that table: ts=# DROP index t_i_idx2; NOTICE: drop_trigger DROP INDEX ts=# DROP index t_i_idx1; NOTICE: drop_trigger DROP INDEX ts=# I looked in pg_depend, but didn't see any trigger with dependency (but maybe not doing it right): ts=# SELECT objid::regclass, * FROM pg_depend WHERE refobjid='t_i_idx'::regclass; (0 rows) This doesn't occur on new tables, just this one.. "ts" is an unused database on our development VM which which I found myself connecting to by habbit (it's the name of most of our customer DBs). I anticipate this may be result of catalog cruftiness resulting from upgrades from 11dev through each of the betas. Specifically this would've been the instance being upgraded when I wrote: https://www.postgresql.org/message-id/flat/20180529171015.GA22903%40telsasoft.com I don't know what else to look at, but wonder if there's any use in debugging this further ? Justin