> -----Original Message----- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > > "Hiroshi Inoue" <[EMAIL PROTECTED]> 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

Reply via email to