Re: Interesting failure mode for initdb
От | Peter Eisentraut |
---|---|
Тема | Re: Interesting failure mode for initdb |
Дата | |
Msg-id | Pine.LNX.4.30.0103101034100.759-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Interesting failure mode for initdb (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Interesting failure mode for initdb
|
Список | pgsql-hackers |
Tom Lane writes: > I think one part of the fix is to modify elog() so that a FATAL exit > results in exit status 1, not 0, if not IsUnderPostmaster. Right. > At the very least we should hack initdb so that --debug removes > "-o /dev/null" from PGSQL_OPT, but can you see any way to provide > filtered stderr output from the backend in the normal mode of operation? I've removed some of the >/dev/null's and the only undesired output I get is of this form: Enabling unlimited row width for system tables. POSTGRES backend interactive interface $Revision: 1.208 $ $Date: 2001/02/24 02:04:51 $ backend> backend> POSTGRES backend interactive interface $Revision: 1.208 $ $Date: 2001/02/24 02:04:51 $ backend> backend> Creating system views. POSTGRES backend interactive interface $Revision: 1.208 $ $Date: 2001/02/24 02:04:51 $ ISTM that the backend shouldn't print a prompt when it's non-interactive. Then maybe we don't need to filter the output at all. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: