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

Re: Proposal - asynchronous functions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Sim Zacks <sim(at)compulab(dot)co(dot)il>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal - asynchronous functions
Date: 2011-04-26 13:06:45
Message-ID: BANLkTi=Np3etBh2h76N6E4LFBODbzVaUHQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Apr 26, 2011 at 8:32 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> We've talked about a number of features that could benefit from some
>> kind of "worker process" facility (e.g. logical replication, parallel
>> query).  So far no one has stepped forward to build such a facility,
>> and I think without that this can't even get off the ground.
>
> Well, this specific thing could be done by just having PG close the
> client connection, not care that it's gone, and have an implied
> 'commit;' at the end.  I'm not saying that I like this approach, but I
> don't think it'd be hard to implement.

Maybe, but that introduces a lot of complications with regards to
things like authentication.  We probably want some API for a backend
to say - hey, please spawn a session with the same user ID and
database association as me, and also provide some mechanism for data
transfer between the two processes.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Sim ZacksDate: 2011-04-26 13:17:48
Subject: Re: Proposal - asynchronous functions
Previous:From: Yves WeißigDate: 2011-04-26 12:42:33
Subject: Re: operator classes for index?

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