Re: Patch to implement pg_current_logfile() function - Mailing list pgsql-hackers

From Gilles Darold
Subject Re: Patch to implement pg_current_logfile() function
Date
Msg-id ee7efb7d-fd41-4dfd-29ed-6d05044d1cbc@dalibo.com
Whole thread Raw
In response to Re: Patch to implement pg_current_logfile() function  ("Karl O. Pinc" <kop@meme.com>)
Responses Re: Patch to implement pg_current_logfile() function  ("Karl O. Pinc" <kop@meme.com>)
Re: Patch to implement pg_current_logfile() function  (Christoph Berg <myon@debian.org>)
Re: Patch to implement pg_current_logfile() function  ("Karl O. Pinc" <kop@meme.com>)
Re: Patch to implement pg_current_logfile() function  ("Karl O. Pinc" <kop@meme.com>)
Re: Patch to implement pg_current_logfile() function  ("Karl O. Pinc" <kop@meme.com>)
Re: Patch to implement pg_current_logfile() function  ("Karl O. Pinc" <kop@meme.com>)
List pgsql-hackers
Le 27/10/2016 à 14:14, Karl O. Pinc a écrit :
> On Thu, 27 Oct 2016 11:07:43 +0200
> Christoph Berg <myon@debian.org> wrote:
>
>> Re: Karl O. Pinc 2016-10-27 <20161026222513.74cd3def@slate.meme.com>
>>> But what if current_logfile contains only a single line?  What
>>> sort of file format does the logfile have?  If you don't know
>>> you can't process the logfile content.
>>>
>>> When there's multiple lines in current_logfile your script might
>>> be looking for a logfile in a particular format.  How is the
>>> script supposed to know the file format of each logfile listed?
>> My idea here would be to always write out two lines, the first for
>> stderr, the second for csvlog, and leave the unused one empty. That's
>> easy to parse from shell scripts.
> That'd work.

I don't think we have to store two lines when just one of the log format
is enabled. If you grep for csvlog in the file and it is not present you
will just know that csvlog is not enabled. If the log format is present
but without the path I think it adds useless information.

The current v8 of the patch only register "format<space>path" for the
enabled log destination, the description of the current_logfiles file
have been change to:

"
A file recording the current log file(s) used by the syslogger and its
log format, stderr or csvlog. Each line of the file is a space separated
list of two elements: the log format and the full path to the log file
including the value of log_directory. The log format must be present in
log_destination to be listed in the file. This file is present only when
logging_collector is activated.
"

The file have been renamed current_logfile*s*


> Agreed.  I can't see adding any more meta-information other than
> file format.
>
> I'm partial to "format <space> path" over just line number, because
> it's more explicit.  Either way works.

This is the format used. Ex:

~$ cat /usr/local/postgresql/data/current_logfile
stderr pg_log/postgresql-2016-10-27_185100.log
csvlog pg_log/postgresql-2016-10-27_185100.csv


> Your comment makes me wonder if pg_current_logfile(), without
> arguments, should instead be "SHOW current_logfile;".
>
> I think not, but have no rationale.  Could this be a good idea?
>

-1, SHOW is used to display run-time parameters values in our case this
is log_destination + log_directory + log_filename. current_logfile is a
filename not a parameter name.

Thanks again for your reviews.

--
Gilles Darold
Consultant PostgreSQL
http://dalibo.com - http://dalibo.org


Attachment

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Issues with building snap packages and psql
Next
From: "Karl O. Pinc"
Date:
Subject: Re: Patch to implement pg_current_logfile() function