Re: BUG #14431: ERROR: XX000: relation 5022917 has no triggers ("should not happen")

Vik Fearing <vik(at)2ndquadrant(dot)fr> writes:
> For the archives, the test case at that link is:

Thanks for copying that into the archives.

The "bar" trigger is actually irrelevant and can be dropped from the
example. The problem is that because the FK constraint on "b" is
deferred, there is an FK-check trigger event waiting to be fired
at the end of the transaction, and we're deleting the pg_trigger
row out from under it.

Ordinarily, we'd prevent you from dropping a trigger that has
unfired events, but the code in tablecmds.c is only checking the
"b" table, and the event in question is for "a"'s trigger.

With the attached patch, you get

ERROR: cannot ALTER TABLE "a" because it has pending trigger events

which I think is a sane behavior, although maybe the precise wording
of the error could be quibbled with. (But improving that would
require fooling with the API of CheckTableNotInUse, which does not
seem worthwhile.)

The other approach we could take is to allow the DROP CONSTRAINT and
silently ignore queued trigger events if we can't find their pg_trigger
row ... but that seems pretty scary in terms of its ability to mask bugs,
and it's not consistent with past choices.

Barring objection, I'll add a test case to this and push it.

regards, tom lane