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

Re: ExecOpenScanR: failed to open relation

From: Jan Wieck <janwieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pam Withnall <Pamw(at)zoom(dot)com(dot)au>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ExecOpenScanR: failed to open relation
Date: 2001-02-26 17:16:19
Message-ID: 200102261716.MAA03277@jupiter.jw.home (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Pam Withnall <Pamw(at)zoom(dot)com(dot)au> writes:
> > in my java code I am creating 3 temporary tables, then calling a stored
> > procedure which calls another stored procedure.
> > then I drop the temporary tables.
> > the first time around , eveything is OK  , then when repeating the action I
> > get
> > "ExecOpenScanR: failed to open relation 2808495 "
>
> If you're using plpgsql, you can't drop and recreate temp tables between
> procedure executions, because the cached query plans for the procedure
> will still refer to the old version of the tables.
>
> Either create the temp table *once* per backend, or use pltcl, which
> doesn't try to cache query plans.

    as  long  as  you  don't  tell  it  to (using spi_prepare and
    spi_execp explicitly in PL/Tcl) :-)


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-02-26 17:22:27
Subject: Re: AW: WAL does not recover gracefully from out-of-disk-sp ace
Previous:From: Ian Lance TaylorDate: 2001-02-26 16:57:08
Subject: Re: Re: [PATCHES] A patch for xlog.c

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