Re: cache invalidation for PL/pgsql functions - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: cache invalidation for PL/pgsql functions
Date
Msg-id CAFj8pRCowbBL-ofAMyQ0KnJqfJAziS3UC1vUpti=k6-YXROxFg@mail.gmail.com
Whole thread Raw
In response to cache invalidation for PL/pgsql functions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: cache invalidation for PL/pgsql functions
List pgsql-hackers


2015-04-28 19:43 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:
The following behavior surprised me, and a few other people at
EnterpriseDB, and one of our customers:

rhaas=# create table foo (a int);
CREATE TABLE
rhaas=# create or replace function test (x foo) returns int as $$begin
return x.b; end$$ language plpgsql;
CREATE FUNCTION
rhaas=# alter table foo add column b int;
ALTER TABLE
rhaas=# select test(null::foo);
ERROR:  record "x" has no field "b"
LINE 1: SELECT x.b
               ^
QUERY:  SELECT x.b
CONTEXT:  PL/pgSQL function test(foo) line 1 at RETURN
rhaas=# \c
You are now connected to database "rhaas" as user "rhaas".
rhaas=# select test(null::foo);
 test
------

(1 row)

I hate to use the term "bug" for what somebody's probably going to
tell me is acceptable behavior, but that seems like a bug.  I guess
the root of the problem is that PL/plgsql's cache invalidation logic
only considers the pg_proc row's TID and xmin when deciding whether to
recompile.  For base types that's probably OK, but for composite
types, not so much.

Thoughts?

It is inconsistent  - and I know so one bigger Czech companies, that use Postgres, had small outage, because they found this issue, when deployed new version of procedure.

The question is what is a cost of fixing

Regards

Pavel 

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: FIX : teach expression walker about RestrictInfo
Next
From: Stephen Frost
Date:
Subject: pg_rewind test race condition..?