Re: Triggers might be caching broken fmgr info - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Triggers might be caching broken fmgr info
Date
Msg-id 19670.990040033@sss.pgh.pa.us
Whole thread Raw
In response to Triggers might be caching broken fmgr info  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> My best guess is that the trigger fmgr lookup in trigger.c:846
>     if (trigger->tgfunc.fn_oid == InvalidOid)
>         fmgr_info(trigger->tgfoid, &trigger->tgfunc);
> might be reading out of an incompletely initialized trigger->tgfunc
> structure.

Yes, that's the problem.

> This is supported by the fact that if I move the
> finfo->fn_oid = functionId;
> assignment in fmgr_info() to the very end of that function, this passes
> gracefully (because the elog comes before the assignment).

I think this is an OK fix, since utils/fmgr/README documents as valid
the technique trigger.c is using:
fn_oid = InvalidOid can be usedto denote a not-yet-initialized FmgrInfo struct.

fmgr_info is clearly failing to live up to the implications of that
commitment.  Please move the fn_oid assignment, and insert a note
that it must be last...

> This might even be a workable fix, but I'm wondering whether elog(ERROR)
> should not flush the trigger cache.

The cache in question is part of the relcache, and no we don't want to
flush it on every elog(ERROR).
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Followup to IRIX6.5 installation of PG 7.1.1
Next
From: Jan Wieck
Date:
Subject: Re: Grammar-problems with pl/pgsql in gram.y