Re: [multithreading] extension compatibility

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [multithreading] extension compatibility
Дата
Msg-id CA+TgmoaD_4RKCcR3mu=vwSt68OzDuedN9cH+qFJ_QLkr98A0kg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [multithreading] extension compatibility  ("Tristan Partin" <tristan@partin.io>)
Ответы Re: [multithreading] extension compatibility
Re: [multithreading] extension compatibility
Список pgsql-hackers
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.

--
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: ssl tests fail due to TCP port conflict
Следующее
От: Paul Jungwirth
Дата:
Сообщение: Re: SQL:2011 application time