Re: relation ### modified while in use

"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