Re: Patch to implement pg_current_logfile() function

Поиск
Список
Период
Сортировка
От Karl O. Pinc
Тема Re: Patch to implement pg_current_logfile() function
Дата
Msg-id 20161119125415.1da454d7@slate.meme.com
обсуждение исходный текст
Ответ на Re: Patch to implement pg_current_logfile() function  (Gilles Darold <gilles.darold@dalibo.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [sqlsmith] Crash on GUC serialization
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: macaddr 64 bit (EUI-64) datatype support