It sounds like there is interest in this feature, can it get added to
the TODO list?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 04/26/2011 11:17 PM, Robert Haas wrote:
> IIRC, we kind of got stuck on the prerequisite wamalloc patch, and that sunk
> the whole thing. :-(
Right, that prerequisite was the largest stumbling block. As I
certainly mentioned back then, it should be possible to get rid of the
imessages depend
On Apr 26, 2011, at 3:32 PM, Markus Wanner wrote:
> Remember the bgworker patches extracted from Postgres-R?
Oh, right. I should have remembered that.
> [ Interestingly enough, one of the complaints I heard back then (not
> necessarily from you) was that there's no user for bgworkers, yet.
> Sm
Markus Wanner wrote:
> On 04/26/2011 02:25 PM, Robert Haas 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
Robert,
On 04/26/2011 02:25 PM, Robert Haas 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 c
On Tue, Apr 26, 2011 at 1:15 PM, Sim Zacks wrote:
> We have tried a similar approach, using plpythonu, by calling import pg and
> then creating a new connection to the database. This does give you an
> autonomous transaction, but not an asynchronous function.
> My use cases are mostly where the fu
On 04/26/2011 06:32 PM, Merlin Moncure wrote:
On Tue, Apr 26, 2011 at 9:24 AM, Robert Haas wrote:
On Tue, Apr 26, 2011 at 10:02 AM, David Fetter wrote:
On Tue, Apr 26, 2011 at 04:17:48PM +0300, Sim Zacks wrote:
On 04/26/2011 03:15 PM, Merlin Moncure wrote:
On Tue, Apr 26, 2011 at 3:28 AM,
On Tue, Apr 26, 2011 at 9:24 AM, Robert Haas wrote:
> On Tue, Apr 26, 2011 at 10:02 AM, David Fetter wrote:
>> On Tue, Apr 26, 2011 at 04:17:48PM +0300, Sim Zacks wrote:
>>> On 04/26/2011 03:15 PM, Merlin Moncure wrote:
>>>
>>> >On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
>>> >>Asynchronou
On Tue, Apr 26, 2011 at 10:02 AM, David Fetter wrote:
> On Tue, Apr 26, 2011 at 04:17:48PM +0300, Sim Zacks wrote:
>> On 04/26/2011 03:15 PM, Merlin Moncure wrote:
>>
>> >On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
>> >>Asynchronous functions
>> >>
>> >>*Problem*
>> >>Postgresql does not ha
On Tue, Apr 26, 2011 at 04:17:48PM +0300, Sim Zacks wrote:
> On 04/26/2011 03:15 PM, Merlin Moncure wrote:
>
> >On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
> >>Asynchronous functions
> >>
> >>*Problem*
> >>Postgresql does not have support for asynchronous function calls.
> >Well, there is a
On 04/26/2011 04:22 PM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Apr 26, 2011 at 8:32 AM, Stephen Frost wrote:
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
On 04/26/2011 03:32 PM, Stephen Frost wrote:
What I don't think we saw was any information about how, exactly, the OP
was planning to implement this in the backend.
Thanks,
Stephen
I'm at stage 1 of this proposal, meaning I know exactly what I want. I
am checking with
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Apr 26, 2011 at 8:32 AM, Stephen Frost wrote:
> > 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 thi
On 04/26/2011 03:15 PM, Merlin Moncure wrote:
On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
Asynchronous functions
*Problem*
Postgresql does not have support for asynchronous function calls.
Well, there is asynchronous support from the client of course. Thus
you can set up a asynchronou
On Tue, Apr 26, 2011 at 8:32 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.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 bui
* Robert Haas (robertmh...@gmail.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 ev
On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
> Add an Async command for functions ( ASYNC my_func(var1,var2) ) and add an
> async optional keyword in trigger statements ( CREATE TRIGGER ... EXECUTE
> ASYNC trig_func() ). This should cause an internal session to be started
> that the function
On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
> Asynchronous functions
>
> *Problem*
> Postgresql does not have support for asynchronous function calls.
Well, there is asynchronous support from the client of course. Thus
you can set up a asynchronous call back to the database with dblink.
Th
Asynchronous functions
*Problem*
Postgresql does not have support for asynchronous function calls.
*Solution*
An asynchronous function would allow a user to call a function and have
it return immediately, while an internal session manages the actual
processing. Any return value(s) of the funct
19 matches
Mail list logo