Skip site navigation (1) Skip section navigation (2)

RE: relation ### modified while in use

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: relation ### modified while in use
Date: 2000-11-02 21:49:35
Message-ID: EKEJJICOHDIEMGPNIFIJMEDICMAA.Inoue@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> -----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:
> > Do we have a conclusion about this thread ?
> > If no,how about changing heap_open(r) so that they allocate
> > Relation descriptors after acquiring a lock on the table ?
> > We would use LockRelation() no longer.
> 
> That won't do by itself,

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" ?

> 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.

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".

Regards.
Hiroshi Inoue

In response to

Responses

pgsql-hackers by date

Next:From: Lamar OwenDate: 2000-11-02 21:51:30
Subject: Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
Previous:From: Tom LaneDate: 2000-11-02 21:49:14
Subject: Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group