Re: Patch: plan invalidation vs stored procedures - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Patch: plan invalidation vs stored procedures
Date
Msg-id 3DE62AEC-7E2E-48C7-82CF-ABDC62A31434@hi-media.com
Whole thread Raw
In response to Re: Patch: plan invalidation vs stored procedures  ("Robert Haas" <robertmhaas@gmail.com>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Le 19 août 08 à 22:03, Robert Haas a écrit :
> All database-driven applications have this problem.  Any time you have
> a database on the backend and interface code on the front-end, you
> need to keep in mind that it won't necessarily be possible to update
> the two of them simultaneously, especially if you have multiple
> back-ends and multiple front-ends, as you almost certainly do.  Even
> if PostgreSQL invalidated plans in the particular situation you're
> discussing, there would still be other problems.  You could add a new,
> non-NULLable column to a table before updating the code that insert
> into that table, or drop an old column that the code still counts on
> being able to access.

Using functions the way Skype uses them means not issuing a single
insert, update or delete directly from your code, but calling a
function which takes care about it.
So you use PostgreSQL transactionnal DDL to roll-out new function
versions at the same time you push the schema modifications, and
commit it all in one go.

> Maybe in your particular environment plan invalidation for functions
> will solve most of the cases you care about

When the code only is a client to an SQL functions API, which
effectively replaces SQL as the way to interact between code and
database, then I believe plan invalidation at function change is the
missing piece.

> , but I respectfully submit
> that there's no substitute for good release engineering.  If you don't
> know exactly what functions are going to be created, modified, or
> dropped on your production servers during each release before you
> actually roll that release out...  you probably need to improve your
> internal documentation.

Agreed :)
- --
dim


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkirK2kACgkQlBXRlnbh1bmxvQCgmowpfnZ5nFRml0mNfj2HRE+3
HJEAnR3G6Lhnb7R4+iSze8xGACwyk4D7
=of1o
-----END PGP SIGNATURE-----


pgsql-hackers by date:

Previous
From: Ron Mayer
Date:
Subject: Re: A smaller default postgresql.conf
Next
From: Andrew Sullivan
Date:
Subject: Re: Patch: plan invalidation vs stored procedures