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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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