Re: [HACKERS] WIP: Separate log file for extension - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: [HACKERS] WIP: Separate log file for extension
Date
Msg-id 31753.1511532076@localhost
Whole thread Raw
In response to Re: [HACKERS] WIP: Separate log file for extension  (Antonin Houska <ah@cybertec.at>)
Responses Re: [HACKERS] WIP: Separate log file for extension  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] WIP: Separate log file for extension  (Jing Wang <jingwangian@gmail.com>)
List pgsql-hackers
Antonin Houska <ah@cybertec.at> wrote:

> Magnus Hagander <magnus@hagander.net> wrote:
>
> > > On Fri, Aug 25, 2017 at 12:12 AM, Antonin Houska <ah@cybertec.at> wrote:
>
> >
> > I like this idea in general.
> >
> >  Then it's supposed to change some of its attributes
> >
> > >  adjust_log_stream_attr(&stream->filename, "my_extension.log");
> >
> > This, however, seems to be wrong.
> >
> > The logfile name does not belong in the extension, it belongs in the
> > configuration file. I think the extension should set it's "stream id" or
> > whatever you want to call it, and then it should be possible to control in
> > postgresql.conf where that log is sent.
>
> Doesn't the last paragraph of
>
> https://www.postgresql.org/message-id/11412.1503912190%40localhost
>
> address your concerns?

Besides a new version of the patch, an example extension is attached that uses
the feature.

> > Also, what if this extension is loaded on demand in a session and not via
> > shared_preload_libraries? It looks like the syslogger only gets the list of
> > configured streams when it starts?
>
> Yes, the syslogger gets the list of streams only when it starts, so the
> extension that wants to use this feature needs to provide the file information
> via shared_preload_libraries. I consider it sufficient because various
> existing logging-related GUCs also can't be changed on-the-fly.
>
> > In short, I think the solution should be more generic, and not "just for extensions".

statement_log.diff demonstrates how the feature can be used by various
subsystems of PG core. Please consider it an example rather than part of the
"separate log patch". Even if there were no other design questions, there's
too much copy & paste in guc.c. I have no good idea right now how to improve
this part.

> o.k. Any idea about dividing the streams into categories? Should they for
> example correspond somehow to categories of GUC variables?
>
> > I completely missed this thread when I did my quick-wip at
> >
https://www.postgresql.org/message-id/flat/CABUevExztL0GORyWM9S4tR_Ft3FmJbRaxQdxj+BQZjpvmRurdw@mail.gmail.com#CABUevExztL0GORyWM9S4tR_Ft3FmJbRaxQdxj+BQZjpvmRurdw@mail.gmail.com
> > -- some of the changes made were close enough that I got the two confused :)
> > Based on the feedback of that one, have you done any performance checks?
>
> I don't expect mere routing of messages into multiple files to bring any
> overhead. I'll run some tests, just out of curiosity.

After having read the thread on your patch I think that the reason you were
asked to evaluate performance was that your patch can possibly make syslogger
a bottleneck. In contrast, my patch does not prevent user from disabling the
syslogger if it (the syslogger) seems to cause performance issues.

--
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at


Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: scan-build plpython stuff
Next
From: Oliver Ford
Date:
Subject: Add RANGE with values and exclusions clauses to the Window Functions