|From:||Antonin Houska <ah(at)cybertec(dot)at>|
|Cc:||Craig Ringer <craig(at)2ndquadrant(dot)com>|
|Subject:||Re: WIP: Separate log file for extension|
|Views:||Raw Message | Whole Thread | Download mbox|
Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 25 August 2017 at 15:12, Antonin Houska <ah(at)cybertec(dot)at> wrote:
> How will this play with syslog? csvlog? etc?
There's nothing special about csvlog: the LogStream structure has a
"destination" field, so if particular extension wants this kind of output, it
simply sets the LOG_DESTINATION_CSVLOG bit here.
LOG_DESTINATION_SYSLOG is a problem because (AFAIK) a single process can
maintain no more than one connection to the syslog server. I don't like the
idea of closing the current connection and opening a different one whenever
the next ereport() is associated with a different stream than the previous
As for LOG_DESTINATION_EVENTLOG, I haven't checked yet.
> I wonder if a level of indirection is appropriate here, where extensions (or
> postgres subsystems, even) provide a log stream label. Then the logging
> backed takes care of using that appropriately for the logging mechanism in
> use; for logging to file that'd generally be separate files. Same for
> CSVlog. Other mechanisms could be left as stubs initially.
> So the outcome would be the same, just without the assumption of specific
> file name and output mechanism baked in.
The example I shown in my previous email was the simplest case I could think
of. But it does not mean that the file name has to be hard-coded in the
extension. Instead of setting the LogStream.filename field, you can pass a
pointer to this field to DefineCustomStringVariable() function, so the
specific GUC can control the value.
|Next Message||Kyotaro HORIGUCHI||2017-08-28 09:24:07||Re: Protect syscache from bloating with negative cache entries|
|Previous Message||Craig Ringer||2017-08-28 09:05:45||Re: psql --batch|