Re: [multithreading] extension compatibility
От | Tristan Partin |
---|---|
Тема | Re: [multithreading] extension compatibility |
Дата | |
Msg-id | D1SFN0923QL1.1DOW0OMWIET3X@partin.io обсуждение исходный текст |
Ответ на | Re: [multithreading] extension compatibility (Robert Haas <robertmhaas@gmail.com>) |
Список | 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@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 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
В списке pgsql-hackers по дате отправления: