Re: Patch to implement pg_current_logfile() function

From: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
To: Gilles Darold <gilles(dot)darold(at)dalibo(dot)com>
Cc: Christoph Berg <myon(at)debian(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to implement pg_current_logfile() function
Date: 2016-11-19 18:54:15
Message-ID: 20161119125415.1da454d7@slate.meme.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 19 Nov 2016 18:59:49 +0100
Gilles Darold <gilles(dot)darold(at)dalibo(dot)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(at)meme(dot)com> wrote:
> >
> >>> On Mon, 7 Nov 2016 23:29:28 +0100
> >>> Gilles Darold <gilles(dot)darold(at)dalibo(dot)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(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2016-11-19 19:29:42 Re: macaddr 64 bit (EUI-64) datatype support
Previous Message Tom Lane 2016-11-19 18:40:53 Re: [sqlsmith] Crash on GUC serialization