Обсуждение: BUG #6707: ERROR: could not open relation with OID

The following bug has been logged on the website:

Bug reference:      6707
Logged by:          LiFeAiR
Email address:      lifeair@gmail.com
PostgreSQL version: 9.1.4
Operating system:   FREE BSD
Description:=20=20=20=20=20=20=20=20

CREATE OR REPLACE FUNCTION test() RETURNS integer AS
$BODY$
DECLARE
 _r RECORD;
BEGIN
CREATE TEMP TABLE test(id int);
_r :=3D ROW(NULL)::test;
_r:=3DNULL;
DROP TABLE test CASCADE;
RETURN    1;
END;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;

  select test();

lifeair@gmail.com writes:
> CREATE OR REPLACE FUNCTION test() RETURNS integer AS
> $BODY$
> DECLARE
>  _r RECORD;
> BEGIN
> CREATE TEMP TABLE test(id int);
> _r := ROW(NULL)::test;
> _r:=NULL;
> DROP TABLE test CASCADE;
> RETURN    1;
> END;
> $BODY$
>   LANGUAGE plpgsql VOLATILE
>   COST 100;

Hmm.  The problem with this is that the DROP TABLE invalidates test's
rowtype, so on a second call the already-compiled "ROW(NULL)::test"
expression refers to a type that no longer exists.

We could fix that by adding datatypes to the set of objects that are
tracked to determine when a cached plan must be invalidated, but I'm
more than a bit hesitant to expend the extra cycles for this, given
the lack of previous complaints and the large number of datatypes
that are mentioned in most plans.

Perhaps it would be good enough to only track types that must be
rowtypes (ie, are mentioned in RowExpr or ConvertRowtypeExpr)?

            regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


Hmm.  The problem with this is that the DROP TABLE invalidates test's
rowtype, so on a second call the already-compiled "ROW(NULL)::test"
expression refers to a type that no longer exists.

> We could fix that by adding datatypes to the set of objects that are
> tracked to determine when a cached plan must be invalidated, but I'm
> more than a bit hesitant to expend the extra cycles for this, given
> the lack of previous complaints and the large number of datatypes
> that are mentioned in most plans.

re previous complaints:

I've run across this in the past but just chalked it up to a
"guess Postgres doesn't like it done that way". I suspect there may
be others in the same boat?

> Perhaps it would be good enough to only track types that must be
> rowtypes (ie, are mentioned in RowExpr or ConvertRowtypeExpr)?

+1

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 201207012259
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAk/xDoYACgkQvJuQZxSWSsiFJwCfQBqt/SUkFHeA8FP+mq3nKtW6
GFwAnjx7WVlCCws7XdsQYDOVYzzpC8iW
=q158
-----END PGP SIGNATURE-----