Re: One process per session lack of sharing

Поиск
Список
Период
Сортировка
От james
Тема Re: One process per session lack of sharing
Дата
Msg-id 4c31772e-4feb-2f81-9bc0-a4f324ecacde@mansionfamily.plus.com
обсуждение исходный текст
Ответ на Re: One process per session lack of sharing  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: One process per session lack of sharing  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: One process per session lack of sharing  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
On 15/07/2016 09:28, Craig Ringer wrote:
> I don't think anyone's considering moving from multi-processing to 
> multi-threading in PostgreSQL. I really, really like the protection 
> that the shared-nothing-by-default process model gives us, among other 
> things.
>
As I understand it, the main issue is that it is hard to integrate 
extensions that use heavyweight runtimes and are focussed on isolation 
within a virtual machine.  Its not just

Perhaps it would be possible for the postmaster (or a delegate process) 
to host such a runtime, and find a way for a user process that wants to 
use such a runtime to communicate with it, whether by copying function 
parameters over RPC or by sharing some of its address space explicitly 
to the runtime to operate on directly.

Such a host delegate process could be explicitly built with multithread 
support and not 'infect' the rest of the code with its requirements.

Using granular RPC is nice for isolation but I am concerned that the 
latencies might be high.





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench - allow to store select results into variables
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: One process per session lack of sharing