Re: Refactoring syslogger piping to simplify adding new log destinations
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Refactoring syslogger piping to simplify adding new log destinations |
| Дата | |
| Msg-id | 20048.1562799567@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Refactoring syslogger piping to simplify adding new logdestinations (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Список | pgsql-hackers |
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Jul-10, Tom Lane wrote:
>> No way that's going to be acceptable for postmaster output.
> Well, we can use both mechanisms simultaneously. Postmaster doesn't emit
> all that much output anyway, so I don't think that's a concern. And
> actually, we still need the pipes from the backend for the odd cases
> where third party code writes to stderr, no?
Yeah, if you don't want to give up capturing random stderr output (and you
shouldn't), that's another issue. But as you say, maybe we could have both
mechanisms. There'd be a synchronization problem for pipe vs queue output
from the same process, but maybe that will be tolerable.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера