Re: [HACKERS] background sessions

Поиск
Список
Период
Сортировка
От Andrew Borodin
Тема Re: [HACKERS] background sessions
Дата
Msg-id CAJEAwVF_2_4go=xqPPUmJNptNENXgfotfA30ECgPZwjhQNnPmQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] background sessions  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Kuntal Ghosh
Дата:
Сообщение: Re: [HACKERS] many copies of atooid() and oid_cmp()
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: [HACKERS] Proposal for changes to recovery.conf API