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

From Christoph Berg
Subject Re: Patch to implement pg_current_logfile() function
Date
Msg-id 20161027175717.qfbuxv7xsh23t3lq@msg.df7cb.de
Whole thread Raw
In response to Re: Patch to implement pg_current_logfile() function  (Gilles Darold <gilles.darold@dalibo.com>)
Responses Re: Patch to implement pg_current_logfile() function  ("Karl O. Pinc" <kop@meme.com>)
List pgsql-hackers
Re: Gilles Darold 2016-10-27 <ee7efb7d-fd41-4dfd-29ed-6d05044d1cbc@dalibo.com>
> > 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

On a closer look, I like this better than my "always two lines"
suggestion. +1.

> -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.

I'm not sure if it's even possible to put non-GUC information in
there. It might also be a performance problem, if pg_current_logfiles
had to read-in for every "select * from pg_settings".

Re: Karl O. Pinc 2016-10-27 <20161027121141.6bd95efd@slate.meme.com>
> Another interface to consider might be a system catalog:
> 
> SELECT * from postgres.pg_current_logfile;
> 
> format | path
> -------+-------------------
> syslog | /some/where/log
> cvslog | /some/where/log.csv
> 
> (2 rows)
> 
> Maybe good if the goal is "interactive use".  Seems like
> overkill to me, but thought I'd present the idea
> anyway.

We were discussing exactly that idea upthread before concluding that a
function with a single return value is much easier to use.

Christoph



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Issues with building snap packages and psql
Next
From: Robert Haas
Date:
Subject: Re: Transactions involving multiple postgres foreign servers