Re: [multithreading] extension compatibility

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