Re: relation ### modified while in use

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: relation ### modified while in use
Date: 2000-11-02 22:01:23
Message-ID: 27100.973202483@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-11-02 22:42:18 Re: Problem with 2 avcuums in parallel
Previous Message Bruce Momjian 2000-11-02 21:54:44 Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)