Re: We should Axe /contrib/start-scripts
От | Tom Lane |
---|---|
Тема | Re: We should Axe /contrib/start-scripts |
Дата | |
Msg-id | 24673.1251331277@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: We should Axe /contrib/start-scripts (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: We should Axe /contrib/start-scripts
|
Список | pgsql-hackers |
Greg Stark <gsstark@mit.edu> writes: > On Thu, Aug 27, 2009 at 12:32 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >> Attached is a simple patch that uses the environment-variable approach. > So with this change you would have the startup script not remove the > lock file? Huh? The startup script shouldn't *ever* remove the lock file. That's been true all along, and this doesn't change it. > This could still fail if the startup script runs some other commands > with & to background them and those commands happen to land with the > pid of postgres? Or the startup script runs pg_ctl within a ( ) > subshell? Yup, and that's been true all along too. This patch makes it possible to write a safe initscript that uses pg_ctl --- it doesn't make it impossible to write an unsafe one. In practice, the situations where people would need to write unsafe constructs have been largely eliminated anyway. Before we had a builtin syslogger process, people often wanted to do something like su - postgres -c "postmaster | logrotate" which is quite unsafe because there's probably an intermediate shell process. No need for that anymore. But notice this is just as unsafe whether you use pg_ctl or postmaster directly ... regards, tom lane
В списке pgsql-hackers по дате отправления: