Re: One process per session lack of sharing

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.

In response to

Responses

Browse pgsql-hackers by date

  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