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

Re: scheduler in core

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
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-01 21:49:53
Message-ID: 162867791003011349v1925eb78vcd7d15021ac6630f@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2010/3/1 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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?

I thing so it is very hard restriction based on using and architecture
of our SPI interface. Our stored procedures are executed inside one
SELECT statement - it is reason for limit. There cannot be two or more
outer transactions. Different implementations has different place of
runtime - it is more near to top of pipeline.

Pavel

>
> See also: http://www.postgresql.org/docs/current/static/plpgsql-porting.html#PLPGSQL-PORTING-EXCEPTIONS
>
> ...Robert
>
> --
> 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
>

In response to

pgsql-hackers by date

Next:From: Josh BerkusDate: 2010-03-01 22:32:01
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration
Previous:From: Robert HaasDate: 2010-03-01 21:43:41
Subject: Re: scheduler in core

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