Re: [multithreading] extension compatibility
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Robert Haas <robertmhaas@gmail.com>, Tristan Partin <tristan@partin.io>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>
Date: 2024-06-06T00:01:12Z
Lists: pgsql-hackers
On 05/06/2024 23:55, Robert Haas wrote: > On Wed, Jun 5, 2024 at 4:32 PM Tristan Partin <tristan@partin.io> wrote: >> 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. > > That's interesting, because I thought Heikki was against having a > runtime toggle. I'm very much in favor of a runtime toggle. To be precise, a PGC_POSTMASTER setting. We'll get a lot more testing if you can easily turn it on/off, and so far I haven't seen anything that would require it to be a compile time option. > I don't think PG_MODULE_MAGIC_REENTRANT is a good syntax. It all looks > great as long as we only ever need the PG_MODULE_MAGIC line to signal > one bit of information, but as soon as you get to two bits it's pretty > questionable, and anything more than two bits is insane. If we want to > do something with the PG_MODULE_MAGIC line, I think it should involve > options-passing of some form rather than just having an alternate > macro name. +1, that would be nicer. -- Heikki Linnakangas Neon (https://neon.tech)