Hi, On 2024-01-23 17:26:19 -0600, Tristan Partin wrote: > 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?
With some libc, including IIRC glibc, FILE* style io starts to use locking, for example. Which we likely shouldn't use as heavily as we do, but we currently do use it for things like COPY. > 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? Building with -pthreads and using threads are separate things... > > > 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. I think there are safe ways to do it, but I don't think we currently reliably do so. It certainly wouldn't be well defined to have a thread created in postmaster, before backends are forked off ("the child process may only execute async-signal-safe operations until such time as one of the exec functions is called"). Greetings, Andres Freund