> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> "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.
>
At least my proposal resolves this flaw.
> >> 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?
IMHO executor should re-parse-rewrite-plan if the target plan
is no longer valid.
> 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?
>
Regards.
Hiroshi Inoue
