From: | james <james(at)mansionfamily(dot)plus(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndQuadrant(dot)com>, AMatveev(at)bitec(dot)ru |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: One process per session lack of sharing |
Date: | 2016-07-15 16:43:22 |
Message-ID: | 4c31772e-4feb-2f81-9bc0-a4f324ecacde@mansionfamily.plus.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-07-15 17:01:43 | Re: One process per session lack of sharing |
Previous Message | Fabien COELHO | 2016-07-15 16:33:33 | Re: pgbench - allow to store select results into variables |