Re: cache invalidation for PL/pgsql functions

2015-04-28 19:43 GMT+02:00 Robert Haas <robertmhaas(at)gmail(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>