Re: Patch to implement pg_current_logfile() function - Mailing list pgsql-hackers
From | Karl O. Pinc |
---|---|
Subject | Re: Patch to implement pg_current_logfile() function |
Date | |
Msg-id | 20161119125415.1da454d7@slate.meme.com Whole thread Raw |
In response to | Re: Patch to implement pg_current_logfile() function (Gilles Darold <gilles.darold@dalibo.com>) |
List | pgsql-hackers |
On Sat, 19 Nov 2016 18:59:49 +0100 Gilles Darold <gilles.darold@dalibo.com> wrote: > Le 19/11/2016 à 16:22, Karl O. Pinc a écrit : > > Hi Gilles, > > > > On Tue, 15 Nov 2016 15:15:52 -0600 > > "Karl O. Pinc" <kop@meme.com> wrote: > > > >>> On Mon, 7 Nov 2016 23:29:28 +0100 > >>> Gilles Darold <gilles.darold@dalibo.com> wrote: > >>>> - Do not write current_logfiles when log_collector is activated > >>>> but log_destination doesn't contained stderr or csvlog. This was > >>>> creating an empty file that can confuse the user. > >> Whether to write current_logfiles only when there's a stderr or > >> csvlog seems dependent up on whether the current_logfiles file is > >> for human or program use. If for humans, don't write it unless it > >> has content. If for programs, why make the program always have to > >> check to see if the file exists before reading it? Failing to > >> check is just one more cause of bugs. > > What are your thoughts on this? I'm leaning toward current_logfiles > > being for programs, not people. So it should be present whenever > > logging_collector is on. > > My though is that it is better to not have an empty file even if > log_collector is on. Thanks. I wrote to be sure that you'd considered my thoughts. I don't see a point in further discussion. I may submit a separate patch to the maintainers when we're ready to send them code so they can see how the code looks with current_logfiles always in existence. Further thoughts below. No need to read them or respond. > Programs can not be confused but human yes, if > the file is present but empty, someone may want to check why this > file is empty. IMO if they want to know why it's empty they could read the docs. > Also having a file containing two lines with just the > log format without path is worst for confusion than having an empty > file. I agree that it makes no sense to list log formats without paths. > In other words, from a program point of view, to gather last log > filename, existence of the file or not doesn't make any difference. > This is the responsibility of the programer to cover all cases. In a > non expert user point of view, there will always the question: why > this file is empty? If the file is not present, the question will > stay: how I to get current log filename? As a non-expert looking at the default data_directory (etc.) almost nothing makes sense. I see the non-expert using the pg_current_logfile() function from within Postgres. I also see a lot of non-experts writing program to get log data and then getting errors when the config changes and current_logfile goes away. Not having data in a opened file generally means a program does nothing. an appropriate action when there are no log files in the filesystem. But not accounting for a non-existent file leads to crashes. Regards, Karl <kop@meme.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
pgsql-hackers by date: