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 20161115151552.5ae06c92@slate.meme.com
Whole thread Raw
In response to Re: Patch to implement pg_current_logfile() function  ("Karl O. Pinc" <kop@meme.com>)
Responses Re: Patch to implement pg_current_logfile() function
List pgsql-hackers
On Sat, 12 Nov 2016 12:59:46 -0600
"Karl O. Pinc" <kop@meme.com> wrote:

> On Mon, 7 Nov 2016 23:29:28 +0100
> Gilles Darold <gilles.darold@dalibo.com> wrote:
> > Here is the v13 of the patch,

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

I don't see a good reason to go past 80 characters on a line here.
Patch attached to be applied on top of v13.

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.

A casual read of the v13 code does not show me that the current_logfiles
file is deleted when the config file is changed so that stderr and
csvlog is no longer output and the user sends a SIGHUP.

Regards,

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Something is broken about connection startup
Next
From: "Karl O. Pinc"
Date:
Subject: Re: Patch to implement pg_current_logfile() function