From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Sehrope Sarkuni <sehrope(at)jackdb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Refactoring syslogger piping to simplify adding new log destinations |
Date: | 2019-07-10 22:59:27 |
Message-ID: | 20048.1562799567@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ryan Lambert | 2019-07-10 23:02:20 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Previous Message | Alvaro Herrera | 2019-07-10 22:54:12 | Re: Refactoring syslogger piping to simplify adding new log destinations |