Re: [multithreading] extension compatibility
От | Heikki Linnakangas |
---|---|
Тема | Re: [multithreading] extension compatibility |
Дата | |
Msg-id | 2efb483c-24cd-4937-b176-89f6c5b9ab92@iki.fi обсуждение исходный текст |
Ответ на | Re: [multithreading] extension compatibility (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [multithreading] extension compatibility
|
Список | pgsql-hackers |
On 06/06/2024 05:47, Robert Haas wrote: > On Wed, Jun 5, 2024 at 10:09 PM Andres Freund <andres@anarazel.de> wrote: >> Maybe. I think shipping a mode where users can fairly simply toggle between >> threaded and process mode will allow us to get this stable a *lot* quicker >> than if we distribute two builds. Most users don't build from source, distros >> will have to pick the mode. If they don't choose threaded mode, we'll not find >> problems. If they do choose threaded mode, we can't ask users to switch to a >> process based mode to check if the problem is related. > > I don't believe that being coercive here is the right approach. I > think distros see the value in compiling with as many things turned on > as possible; when they ship with something turned off, it's because > it's unstable or introduces weird dependencies or has some other > disadvantage. I presume there's no harm in building with multithreading support. If you don't want to use it, put "multithreading=off" in your config file (which will presumably be the default for a while). If we're worried about the performance impact of thread-local variables in particular, we can try to measure that. I don't think it's material though. If there is some material harm from compiling with multithreading support even if you're not using it, we should try to fix that. I'm not dead set against having a compile-time option, but I don't see the need for it at the moment. -- Heikki Linnakangas Neon (https://neon.tech)
В списке pgsql-hackers по дате отправления: