Re: new GUC var: autovacuum_process_all_tables

On Fri, 2009-02-06 at 00:07 +0000, Greg Stark wrote:
> On Thu, Feb 5, 2009 at 11:57 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >
> > Writing an application maintenance utility in PL/pgSQL is much better
> > than having to write it for all the different servers an application may
> > need to run on.
>
> Welcome to the suction effect. If your scheduler is in the database
> then you're stuck with the interfaces the database provides. When you
> use those interfaces you're going to be stuck with whatever tools work
> with them. Imagine trying to compose MIME email in plpgsql or do dns
> lookups or interface with your C application code. Plpgsql is
> singularly unsuited for anything other than database work. Yes we have
> other languages but there are still relatively few and having them
> running within a PL interface makes integrating with the rest of their
> systems more awkward. And more dangerous -- consider what a simple
> memory management bug can do if it's in a database backend instead of
> a network client.

You're saying that because it would be wrong for some things, we're not
going to allow it at all. Re-read what you've written and you'll see
that same argument would ban all PLs, on the basis that we have external
language environments. I don't suppose you believe that.

There are many in-database-only actions that people want to schedule,
not just autovacuum. End of month data deletion, partition setup,
pre-joined or summary table creation, FY rollover calculations etc etc.
None of those have anything to do with the world outside the DB.

If writing database functions is possible and sometimes desirable in
Postgres, then scheduling them is also sometimes desirable also. I would
hope that we can give our users the choice.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support