Re: One process per session lack of sharing

On 14 July 2016 at 16:41, <AMatveev(at)bitec(dot)ru> wrote:

> Hi
>
> > On Tue, Jul 12, 2016 at 9:18 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> AMatveev(at)bitec(dot)ru writes:
> >>> Is there any plan to implement "session per thread" or "shared
> >>> sessions between thread"?
> >>...
> >> so
> >> there's not that much motivation to do a ton of work inside the database
> >> to solve it there.
>
> > I agree that there's not really a plan to implement this, but I don't
> > ...
>
> > So, I actually think it would be a good idea to think about this.
>
> I just want to note that converting global variables to thread-specific
> variables.
>

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.

I'm personally not absolutely opposed to threading, but you'll find it hard
to convince anyone it's worth the huge work required to ensure that
everything in PostgreSQL is done thread-safely, adapt all our logic to
handle thread IDs where we use process IDs, etc. It'd be a massive amount
of work for no practical gain for most users, and a huge reliability loss
in the short to medium term as we ironed out all the bugs.

Where I agreed with you, and where I think Robert sounded like he was
agreeing, was that our current design where we have one executor per user
sessions and can't suspend/resume sessions is problematic.

> It's large work offcourse.
> But it's not seemed to be a ton of work.
>

Er.... yeah, it really is. It's not just the mechanical changes. It's
verifying that everything's correct on all the supported platforms.
Ensuring that all the C library stuff we do is thread-safe, all the SSL
stuff, etc. Getting rid of all the function-static variable use. Lots more.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services