Re: Refactoring syslogger piping to simplify adding new log destinations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactoring syslogger piping to simplify adding new log destinations
Date
Msg-id 20048.1562799567@sss.pgh.pa.us
Whole thread Raw
In response to Re: Refactoring syslogger piping to simplify adding new logdestinations  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Refactoring syslogger piping to simplify adding new logdestinations
Next
From: Ryan Lambert
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)