From: | "Tristan Partin" <tristan(at)neon(dot)tech> |
---|---|
To: | "Andres Freund" <andres(at)anarazel(dot)de> |
Cc: | "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, "Alexander Bayandin" <alexander(at)neon(dot)tech> |
Subject: | Re: Remove pthread_is_threaded_np() checks in postmaster |
Date: | 2024-01-23 23:26:19 |
Message-ID: | CYMH3F7DEFXB.1ZMPD4IZNXS27@neon.tech |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue Jan 23, 2024 at 4:23 PM CST, Andres Freund wrote:
> Hi,
>
> On 2024-01-23 15:50:11 -0600, Tristan Partin wrote:
> > What is keeping us from using pthread_sigmask(3) instead of sigprocmask(2)?
>
> We would need to make sure to compile with threading support everywhere. One
> issue is that on some platforms things get slower once you actually start
> using pthreads.
What are examples of these reduced performance platforms?
From reading the meson.build files, it seems like building with
threading enabled is the future, so should we just rip the band-aid off
for 17?
> > If an extension can guarantee that threads that get launched by it don't
> > interact with anything Postgres-related, would that be enough to protect
> > from any fork(2) related issues?
>
> A fork() while threads are running is undefined behavior IIRC, and undefined
> behavior isn't limited to a single thread. You'd definitely need to use
> pthread_sigprocmask etc to address that aspect alone.
If you can find a resource that explains the UB, I would be very
interested to read that. I found a SO[0] answer that made it seem like
this actually wasn't the case.
[0]: https://stackoverflow.com/a/42679479/7572728
--
Tristan Partin
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-01-23 23:32:08 | Re: [PATCH] Add native windows on arm64 support |
Previous Message | Tom Lane | 2024-01-23 22:33:34 | Re: Support TZ format code in to_timestamp() |