Re: [HACKERS] fork()-safety, thread-safety

On 6 October 2017 at 08:06, Andres Freund wrote: > On 2017-10-06 07:59:40 +0800, Craig Ringer wrote: >> The only thing that gets me excited about a threaded postgres is the >> ability to have a PL/Java, PL/Mono etc that don't suck. We could do >> some really cool things that

Re: [HACKERS] fork()-safety, thread-safety

On October 5, 2017 5:15:41 PM PDT, Tom Lane wrote: >Andres Freund writes: >> On 2017-10-06 07:59:40 +0800, Craig Ringer wrote: >>> The only thing that gets me excited about a threaded postgres is the >>> ability to have a PL/Java, PL/Mono etc that don't

Re: [HACKERS] fork()-safety, thread-safety

Andres Freund writes: > On 2017-10-06 07:59:40 +0800, Craig Ringer wrote: >> The only thing that gets me excited about a threaded postgres is the >> ability to have a PL/Java, PL/Mono etc that don't suck. We could do >> some really cool things that just aren't practical right

Re: [HACKERS] fork()-safety, thread-safety

On 2017-10-06 07:59:40 +0800, Craig Ringer wrote: > The only thing that gets me excited about a threaded postgres is the > ability to have a PL/Java, PL/Mono etc that don't suck. We could do > some really cool things that just aren't practical right now. Faster parallelism with a lot less

Re: [HACKERS] fork()-safety, thread-safety

On 6 October 2017 at 06:49, Tom Lane wrote: > Andres Freund writes: >> On 2017-10-05 17:31:07 -0500, Nico Williams wrote: >>> You don't think eliminating a large difference between handling of WIN32 >>> vs. POSIX is a good reason? > >> I seems like you'd

Re: [HACKERS] fork()-safety, thread-safety

On 2017-10-05 18:49:22 -0400, Tom Lane wrote: > (There's certainly an argument to be made that no-one cares about > platforms without thread support anymore. But I'm unconvinced that > rewriting existing code that works fine is the most productive > way to exploit such a choice if we were to make

Re: [HACKERS] fork()-safety, thread-safety

Andres Freund writes: > On 2017-10-05 17:31:07 -0500, Nico Williams wrote: >> You don't think eliminating a large difference between handling of WIN32 >> vs. POSIX is a good reason? > I seems like you'd not really get a much reduced set of differences, > just a *different*

Re: [HACKERS] fork()-safety, thread-safety

On Thu, Oct 05, 2017 at 03:34:41PM -0700, Andres Freund wrote: > On 2017-10-05 17:31:07 -0500, Nico Williams wrote: > > > >vfork() is widely demonized, but it's actually quite superior > > > >(performance-wise) to fork() when all you want to do is exec-or-exit > > > >since no page

Re: [HACKERS] fork()-safety, thread-safety

Hi, On 2017-10-05 17:31:07 -0500, Nico Williams wrote: > > >vfork() is widely demonized, but it's actually quite superior > > >(performance-wise) to fork() when all you want to do is exec-or-exit > > >since no page copying (COW or otherwise) needs be done when using > > >vfork().

Re: [HACKERS] fork()-safety, thread-safety

On Thu, Oct 05, 2017 at 03:13:07PM -0700, Andres Freund wrote: > On 2017-10-05 17:02:22 -0500, Nico Williams wrote: > >A quick look at the functions called on the child side of fork() > >makes me think that it's unlikely that the children here use > >async-signal-safe functions only. >

Re: [HACKERS] fork()-safety, thread-safety

Hi, On 2017-10-05 17:02:22 -0500, Nico Williams wrote: >A quick look at the functions called on the child side of fork() >makes me think that it's unlikely that the children here use >async-signal-safe functions only. That's not a requirement unless you're using fork *and* threads.

[HACKERS] fork()-safety, thread-safety

A thread on parallelization made me wonder so I took a look: - src/bin/*/parallel.c uses threads on WIN32 - src/bin/*/parallel.c uses fork() on not-WIN32 (Ditto src/bin/pg_basebackup/pg_basebackup.c and src/backend/postmaster/syslogger.c.) A quick look at the functions called on the