Re: [multithreading] extension compatibility
От | Heikki Linnakangas |
---|---|
Тема | Re: [multithreading] extension compatibility |
Дата | |
Msg-id | 1f7497a2-5c84-44c0-b777-0aa9878fea2b@iki.fi обсуждение исходный текст |
Ответ на | Re: [multithreading] extension compatibility (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [multithreading] extension compatibility
|
Список | 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)
В списке pgsql-hackers по дате отправления: