Re: [HACKERS] background sessions - Mailing list pgsql-hackers

From Andrew Borodin
Subject Re: [HACKERS] background sessions
Date
Msg-id CAJEAwVF_2_4go=xqPPUmJNptNENXgfotfA30ECgPZwjhQNnPmQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] background sessions  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
2017-01-12 9:01 GMT+05:00 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>:
> On 1/10/17 10:58 AM, Robert Haas wrote:
>> On Thu, Dec 29, 2016 at 5:18 PM, Peter Eisentraut
>> <peter.eisentraut@2ndquadrant.com> wrote:
>>> For additional entertainment, I include patches that integrate
>>> background sessions into dblink.  So dblink can open a connection to a
>>> background session, and then you can use the existing dblink functions
>>> to send queries, read results, etc.  People use dblink to make
>>> self-connections to get autonomous subsessions, so this would directly
>>> address that use case.  The 0001 patch is some prerequisite refactoring
>>> to remove an ugly macro mess, which is useful independent of this.  0002
>>> is the actual patch.
>>
>> Would that constitute a complete replacement for pg_background?
>
> I think so.
That constitute replacement on the set of existing functionality.
It's not certain whether new features for pg_background would be
coherent with db_link ideology.
E.g. if one day we implement data exchange between two running queries
for pg_background, it would be in conflict with db_link ideology.

I have not opinion on is db_link or pg_background apropriate place for
this functionality. Just mentioning some thoughts.

BTW can we have an automatic FWD for bgsessions? Sounds crazy for me,
but technically make sense.

Best regards, Andrey Borodin.



pgsql-hackers by date:

Previous
From: Kuntal Ghosh
Date:
Subject: Re: [HACKERS] many copies of atooid() and oid_cmp()
Next
From: Fujii Masao
Date:
Subject: Re: [HACKERS] Proposal for changes to recovery.conf API