Re: [multithreading] extension compatibility
Tristan Partin <tristan@partin.io>
From: "Tristan Partin" <tristan@partin.io>
To: "Robert Haas" <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "Andres
Freund" <andres@anarazel.de>, "Thomas Munro" <thomas.munro@gmail.com>,
"Heikki Linnakangas" <hlinnaka@iki.fi>
Date: 2024-06-05T20:32:18Z
Lists: pgsql-hackers
Attachments
- multithreading.patch (text/x-patch)
On Wed Jun 5, 2024 at 3:05 PM CDT, Robert Haas wrote: > ... > > == Extension Compatibility Solutions == > > The attached patch is a sketch of one possible approach: PostgreSQL > signals whether it is multithreaded by defining or not defining > PG_MULTITHREADING in pg_config_manual.h, and an extension signals > thread-readiness by defining PG_THREADSAFE_EXTENSION before including > any PostgreSQL headers other than postgres.h. If PostgreSQL is built > multithreaded and the extension does not signal thread-safety, you get > something like this: > > ../pgsql/src/test/modules/dummy_seclabel/dummy_seclabel.c:20:1: error: > static assertion failed due to requirement '1 == 0': must define > PG_THREADSAFE_EXTENSION or use unthreaded PostgreSQL > PG_MODULE_MAGIC; > > I'm not entirely happy with this solution because the results are > confusing if PG_THREADSAFE_EXTENSION is declared after including > fmgr.h. Perhaps this can be adequately handled by documenting and > demonstrating the right pattern, or maybe somebody has a better idea. > > Another idea I considered was to replace the PG_MODULE_MAGIC; > declaration with something that allows for arguments, like > PG_MODULE_MAGIC(.process_model = false, .thread_model = true). But on > further reflection, that seems like the wrong thing. AFAICS, that's > going to tell you at runtime about something that you really want to > know at compile time. But this kind of idea might need more thought if > we decide that the *same* build of PostgreSQL can either launch > processes or threads per session, because then we'd to know which > extensions were available in whichever mode applied to the current > session. Not entirely sure how I feel about the approach you've taken, but here is a patch that Heikki and I put together for extension compatibility. It's not a build time solution, but a runtime solution. Instead of PG_MODULE_MAGIC, extensions would use PG_MAGIC_MODULE_REENTRANT. There is a GUC called `multithreaded` which controls the variable IsMultithreaded. We operated under the assumption that being able to toggle multithreading and multi-processing without recompiling has value. -- Tristan Partin https://tristan.partin.io