> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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
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?
In response to
pgsql-hackers by date
|Next:||From: Hiroshi Inoue||Date: 2000-11-03 13:51:26|
|Subject: RE: relation ### modified while in use |
|Previous:||From: Frank Joerdens||Date: 2000-11-03 13:34:35|
|Subject: DBD::Pg installation seems to fail with 7.1 libs|