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