Re: [multithreading] extension compatibility

From: "Tristan Partin" <tristan(at)partin(dot)io>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "Andres Freund" <andres(at)anarazel(dot)de>, "Thomas Munro" <thomas(dot)munro(at)gmail(dot)com>, "Heikki Linnakangas" <hlinnaka(at)iki(dot)fi>
Subject: Re: [multithreading] extension compatibility
Date: 2024-06-05 22:21:46
Message-ID: D1SFN0923QL1.1DOW0OMWIET3X@partin.io
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed Jun 5, 2024 at 3:56 PM CDT, Robert Haas wrote:
> On Wed, Jun 5, 2024 at 4:32 PM Tristan Partin <tristan(at)partin(dot)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 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.

I agree that this method doesn't lend itself to future extensibility.

--
Tristan Partin
https://tristan.partin.io

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2024-06-05 22:46:17 Re: First draft of PG 17 release notes
Previous Message Tom Lane 2024-06-05 21:37:15 Re: ssl tests fail due to TCP port conflict