Skip site navigation (1) Skip section navigation (2)

Re: scheduler in core

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: scheduler in core
Date: 2010-03-02 00:10:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> IMNSHO, an 'in core' scheduler would be useful. however, I think
>> before you tackle a scheduler, we need proper stored procedures. Our
>> existing functions don't cut it because you can manage the transaction
>> state yourself.

> Did you mean that you "can't" manage the transaction state yourself?

> Has anyone given any thought to what would be required to relax this
> restriction?  Is this totally impossible given our architecture, or
> just a lack of round tuits?

There is lots and lots of discussion of that in the archives.  It's
fundamentally impossible for PL functions done in the current style to
start or commit transactions, unless you resort to dblink-style kluges.
What's been discussed is some sort of structure that would allow a chunk
of PL code to execute "outside" a transaction and thus issue its own
begin and commit commands.  This idea is what Merlin is calling a stored
procedure, though personally I dislike that terminology.  Anyway,
nothing's got past the arm-waving stage as yet.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Ed L.Date: 2010-03-02 00:12:36
Subject: Re: Hung postmaster (8.3.9)
Previous:From: Andrew DunstanDate: 2010-03-02 00:08:05
Subject: Re: [Feature request] variable declaration of anonymous composite data type in PL/pgSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group