Re: Patch: plan invalidation vs stored procedures

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: plan invalidation vs stored procedures
Date: 2008-08-19 20:22:01
Message-ID: 3DE62AEC-7E2E-48C7-82CF-ABDC62A31434@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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-----

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Sullivan 2008-08-19 20:22:43 Re: Patch: plan invalidation vs stored procedures
Previous Message Ron Mayer 2008-08-19 20:08:01 Re: A smaller default postgresql.conf