Re: WIP - syslogger infrastructure changes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WIP - syslogger infrastructure changes
Дата
Msg-id 20196.1252959278@sss.pgh.pa.us
обсуждение исходный текст
Ответ на WIP - syslogger infrastructure changes  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: WIP - syslogger infrastructure changes  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> First, the patch removes the logging_collector parameter and basically
> assumes that logging_collector is always on.

I don't find that to be a good idea, and you certainly have not made
a case why we should change it.  I can't see any reason why pushing
functionality out of backends and downstream to the syslogger process
is an improvement.  What it's more likely to do is create a processing
bottleneck and a single point of failure.

> ... Given that the syslogger is now
> always started, those that actually *want* logging to stderr (which I
> claim is a low number of people, but that's a different story) will
> have it go through the syslogger and then to the stderr of syslogger.

That design doesn't work because there is then *no* way to recover from
a syslogger crash.  You no longer have access to the original stderr
file once the postmaster has redirected stderr to syslogger.  We can
live with that so long as syslogger's stderr output isn't very
interesting, but not if it's going to be the main log channel.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: generic copy options
Следующее
От: Jaime Casanova
Дата:
Сообщение: Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)