Hi, On 2023-06-05 17:51:57 +0300, Heikki Linnakangas wrote: > If there are no major objections, I'm going to update the developer FAQ, > removing the excuses there for why we don't use threads [1].
I think we should do this even if there's no concensus to slowly change to threads. There's clearly no concensus on the opposite either. > # Transition period > > The transition surely cannot be done fully in one release. Even if we could > pull it off in core, extensions will need more time to adapt. There will be > a transition period of at least one release, probably more, where you can > choose multi-process or multi-thread model using a GUC. Depending on how it > goes, we can document it as experimental at first. One interesting bit around the transition is what tooling we ought to provide to detect problems. It could e.g. be reasonably feasible to write something checking how many read-write global variables an extension has on linux systems. > # Extensions > > A lot of extensions also contain global variables or other things that break > in a multi-threaded environment. We need a way to label extensions that > support multi-threading. And in the future, also extensions that *require* a > multi-threaded server. > > Let's add flags to the control file to mark if the extension is thread-safe > and/or process-safe. If you try to load an extension that's not compatible > with the server's mode, throw an error. I don't think the control file is the right place - that seems more like something that should be signalled via PG_MODULE_MAGIC. We need to check this not just during CREATE EXTENSION, but also during loading of libraries - think of shared_preload_libraries. > # Restart on crash > > If a backend process crashes, postmaster terminates all other backends and > restarts the system. That's hard (impossible?) to do safely if everything > runs in one process. We can continue have a separate postmaster process that > just monitors the main process and restarts it on crash. Yea, we definitely need the supervisor function in a separate process. Presumably that means we need to split off some of the postmaster responsibilities - e.g. I don't think it'd make sense to handle connection establishment in the supervisor process. I wonder if this is something that could end up being beneficial even in the process world. A related issue is that we won't get SIGCHLD in the supervisor process anymore. So we'd need to come up with some design for that. Greetings, Andres Freund
