Re: Weird failure with latches in curculio on v15
От | Andres Freund |
---|---|
Тема | Re: Weird failure with latches in curculio on v15 |
Дата | |
Msg-id | 20230201181827.5pcnqdnt3nlcjgex@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Weird failure with latches in curculio on v15 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Weird failure with latches in curculio on v15
|
Список | pgsql-hackers |
Hi, On 2023-02-01 12:27:19 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2023-02-01 12:08:24 -0500, Robert Haas wrote: > >> I like the idea of not relying on system(). In most respects, doing > >> fork() + exec() ourselves seems superior. We can control where the > >> output goes, what we do while waiting, etc. But system() runs the > >> command through the shell, so that for example you don't have to > >> invent your own way of splitting a string into words to be passed to > >> exec[whatever](). I've never understood how you're supposed to get > >> that behavior other than by calling system(). > > > We could just exec the shell in the forked process, using -c to invoke > > the command. That should give us pretty much the same efficiency as > > system(), with a lot more control. > > The main thing that system() brings to the table is platform-specific > knowledge of where the shell is. I'm not very sure that we want to > wire in "/bin/sh". We seem to be doing OK with using SHELLPROG in pg_regress, which just seems to be using $SHELL from the build environment. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: