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-10-31 03:35:40
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

Hi Gilles,

On Sat, 29 Oct 2016 22:00:08 +0200
Gilles Darold <gilles(dot)darold(at)dalibo(dot)com> wrote:

> The attached v10 of the current_logfiles patch

Attached is a patch to apply on top of the v10 patch.

It updates current_logfiles only once per log rotation.
I see no reason to open and write the file twice
if both csvlog and stderr logging is happening.

I have 2 more questions.

I don't understand why you're calling
logfile_writename(last_file_name, last_csv_file_name);
in the SIGHUP code. Presumably you've already
written the old logfile names to current_logfiles.
On SIGHUP you want to write the new names, not
the old ones. But the point of the SIGHUP code
is to look for changes in logfile writing and then
call logfile_rotate() to make those changes. And
logfile_rotate() calls logfile_writename() as appropriate.
Shouldn't the logfile_writename call in the SIGHUP
code be eliminated?

Second, and I've not paid really close attention here,
you're calling logfile_writename() with last_file_name
and last_csv_file_name in a number of places. Are you
sure that last_file_name and last_csv_file_name is reset
to the empty string if stderr/csvlog logging is turned
off and the config file re-read? You might be recording
that logging is going somewhere that's been turned off
by a config change. I've not noticed last_file_name and
(especially) last_csv_file_name getting reset to the empty

FYI, ultimately, in order to re-try writes to current_logfiles
after ENFILE and EMFILE failure, I'm thinking that I'll probably
wind up with logfile_writename() taking no arguments. It will
always write last_file_name and last_csv_file_name. Then it's
a matter of making sure that these variables contain accurate
values. It would be helpful to let me know if you have any
insight regards config file re-read and resetting of these
variables before I dive into writing code which retries writes to


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

Attachment Content-Type Size
patch_pg_current_logfile-v10.diff.only_once application/octet-stream 2.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-10-31 03:37:47 Re: sequential scan result order vs performance
Previous Message Kyotaro HORIGUCHI 2016-10-31 01:39:12 Re: asynchronous execution