"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> Doesn't current heap_open() have a flaw that even the first
> use of a relation in a transaction may cause an error
> "relation ### modified while in use" ?
Sure, that was the starting point of the discussion.
>> because that will open us up to failures when
>> a relcache invalidation arrives mid-transaction and we don't happen to
>> have the relation open at the time. We could still have parse/plan
>> results that depend on the old relation definition.
> PL/pgSQL already prepares a plan at the first execution
> time and executes the plan repeatedly after that.
> We would have general PREPARE/EXECUTE feature in the
> near fututre. IMHO another mechanism to detect plan invali
> dation is needed.
Yes, we need the ability to invalidate cached plans. But that doesn't
have anything to do with this issue, IMHO. The problem at hand is that
a plan may be invalidated before it is even finished building. Do you
expect the parse-rewrite-plan-execute pipeline to be prepared to back up
and restart if we notice a relation schema change report halfway down the
process? How will we even *know* whether the schema change invalidates
what we've done so far, unless we have a first-use-in-transaction flag?
> BTW,I sometimes see
> ERROR: SearchSysCache: recursive use of cache 10(16)
> under small MAXNUMMESSAGES environment.
> I'm not sure about the cause but suspicious if sufficiently
> many system relations are nailed for "cache state reset".
Does this occur after a prior error message? I have been suspicious
because there isn't a mechanism to clear the syscache-busy flags during
xact abort. If we elog() out of a syscache fill operation, seems like
the busy flag will be left set, leading to exactly the above error on
later xacts' attempts to use that syscache. I think we need an
AtEOXact_Syscache routine that runs around and clears the busy flags.
(In the commit case, perhaps it should issue debug notices if it finds
any that are set.)
regards, tom lane