Re: pg_background (and more parallelism infrastructure patches) - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: pg_background (and more parallelism infrastructure patches)
Date
Msg-id 543D8DED.5060702@2ndquadrant.com
Whole thread Raw
In response to Re: pg_background (and more parallelism infrastructure patches)  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 09/10/14 00:32, Andres Freund wrote:
>>  From c835a06f20792556d35a0eee4c2fa21f5f23e8a3 Mon Sep 17 00:00:00 2001
>> From: Robert Haas <rhaas@postgresql.org>
>> Date: Fri, 11 Jul 2014 09:53:40 -0400
>> Subject: [PATCH 6/6] pg_background: Run commands in a background worker, and
>>   get the results.
>>
>> The currently-active GUC values from the user session will be copied
>> to the background worker.  If the command returns a result set, you
>> can retrieve the result set; if not, you can retrieve the command
>> tags.  If the command fails with an error, the same error will be
>> thrown in the launching process when the results are retrieved.
>> Warnings and other messages generated by the background worker, and
>> notifications received by it, are also propagated to the foreground
>> process.
>
> I got to ask: Why is it helpful that we have this in contrib? I have a
> good share of blame to bear for that, but I think we need to stop
> dilluting contrib evermore with test programs. These have a place, but I
> don't think it should be contrib.
>

I don't see this as just mere test module, it seems to provide actual 
useful functionality (I still dream of it being extended with scheduler 
eventually and even if it's not, you still get "asynchronous transactions").

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: WIP: dynahash replacement for buffer table
Next
From: Petr Jelinek
Date:
Subject: Re: proposal: plpgsql - Assert statement