Re: Linux LSB init script
От | Kevin Grittner |
---|---|
Тема | Re: Linux LSB init script |
Дата | |
Msg-id | 4AC347E2020000250002B4DB@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Linux LSB init script (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Linux LSB init script
(Peter Eisentraut <peter_e@gmx.net>)
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> wrote: > Peter Eisentraut <peter_e@gmx.net> wrote: >> On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote: >>> It seems like there is some support for what this patch is trying >>> to do, but much disagreement about the details of how to get >>> there. Where do we go from here? >> >> I think the next step would be to outline what changes would be >> necessary in pg_ctl to implement LSB behavior. And then decide >> case by case whether it should become the default, an option, or is >> not appropriate for pg_ctl. >> >> Kevin apparently sort of agreed to do that when he came back. Right. It seems that, in addition to the above, there also remains some disagreement about: (1) how much checking the script should do to provide error messages and exit codes which target the specific problems versus generic "I'm broken" messages for problems which prevent it from getting to the point of being able to run pg_ctl, (2) whether the log functions required by the standard should be used, or whether we should assume that output to stdout and/or stderr (which the standard says may be silently discarded without showing anywhere) should be used instead, (3) whether we should provide comments of the general intent of sections of code when the implementing code is providing functionality required by the standard, versus assuming that the reader can match the code portions to the relevant sections of the standard without supporting comments. In general, I think most of the disputed points revolve around balancing strict compliance against keeping the script short. (The existing Linux script is about 100 lines of shell script; the LSB conforming proposal, without any pg_ctl changes which might make it shorter, is about 300 lines.) There's also disagreement about whether we should source /lib/lsb/init-functions -- which is required by the LSB standard, and provides the logging functions which the standard requires scripts to use. > Given the lack of progress here, I'm going to move this one to > "Returned with Feedback" for now. I think Kevin is busy with his > non-PostgreSQL life, and there's always next CommitFest. Yeah, I'm back now, but given the research needed and the level of disagreement, completion in the CF seems unlikely. If all the stars align correctly and this gets completed in the next two weeks, we can always resurrect it. -Kevin
В списке pgsql-hackers по дате отправления: