Re: Reopen logfile on SIGHUP

At Sat, 1 Sep 2018 19:52:16 +0300, Alexander Korotkov wrote in > On Thu, Aug 30, 2018 at 2:44 PM Kyotaro HORIGUCHI > wrote: > > At Thu, 30 Aug 2018 13:42:42 +0300, Alexander Korotkov > > wrote in > > > > > It seems that http://commitfest.cputube.org/ runs only "make check" on > > >

Re: Reopen logfile on SIGHUP

On Thu, Aug 30, 2018 at 2:44 PM Kyotaro HORIGUCHI wrote: > At Thu, 30 Aug 2018 13:42:42 +0300, Alexander Korotkov > wrote in > > > It seems that http://commitfest.cputube.org/ runs only "make check" on > > Windows. But my Postgres Pro colleagues checked that tests passed on > > 32-bit and

Re: Reopen logfile on SIGHUP

Hello. At Thu, 30 Aug 2018 13:42:42 +0300, Alexander Korotkov wrote in > It seems that http://commitfest.cputube.org/ runs only "make check" on > Windows. But my Postgres Pro colleagues checked that tests passed on > 32-bit and 64-bit versions of Windows Server 2008. Also I made some >

Re: Reopen logfile on SIGHUP

On Wed, Aug 29, 2018 at 12:01 PM Alexander Korotkov wrote: > On Wed, Aug 29, 2018 at 5:05 AM Kyotaro HORIGUCHI > wrote: > > At Tue, 28 Aug 2018 18:50:31 +0300, Alexander Korotkov > > wrote in > > > > > Also I found that this new pg_ctl isn't covered with tests at all. So > > > I've added

Re: Reopen logfile on SIGHUP

Hi! On Wed, Aug 29, 2018 at 5:05 AM Kyotaro HORIGUCHI wrote: > At Tue, 28 Aug 2018 18:50:31 +0300, Alexander Korotkov > wrote in > > > Also I found that this new pg_ctl isn't covered with tests at all. So > > I've added very simple tap tests, which ensures that when log file was > >

Re: Reopen logfile on SIGHUP

At Tue, 28 Aug 2018 18:50:31 +0300, Alexander Korotkov wrote in > On Tue, Aug 21, 2018 at 4:48 AM Kyotaro HORIGUCHI > wrote: > > > > At Fri, 10 Aug 2018 15:33:26 +0300, Alexander Kuzmenkov > > wrote in > > <5142559a-82e6-b3e4-d6ed-8fd2d240c...@postgrespro.ru> > > > On 08/09/2018 10:33 AM,

Re: Reopen logfile on SIGHUP

At Tue, 21 Aug 2018 11:27:46 +0900, Michael Paquier wrote in <20180821022745.ge2...@paquier.xyz> > On Tue, Aug 21, 2018 at 09:26:54AM +0900, Kyotaro HORIGUCHI wrote: > > I suspect that something bad can happen on Windows. > > [troll mode] > More and even worse things than that could happen on

Re: Reopen logfile on SIGHUP

On Tue, Aug 21, 2018 at 4:48 AM Kyotaro HORIGUCHI wrote: > > At Fri, 10 Aug 2018 15:33:26 +0300, Alexander Kuzmenkov > wrote in > <5142559a-82e6-b3e4-d6ed-8fd2d240c...@postgrespro.ru> > > On 08/09/2018 10:33 AM, Kyotaro HORIGUCHI wrote: > > > > > > - Since I'm not sure unlink is signal-handler

Re: Reopen logfile on SIGHUP

On Tue, Aug 21, 2018 at 09:26:54AM +0900, Kyotaro HORIGUCHI wrote: > I suspect that something bad can happen on Windows. [troll mode] More and even worse things than that could happen on Windows. [/troll mode] -- Michael signature.asc Description: PGP signature

Re: Reopen logfile on SIGHUP

At Fri, 10 Aug 2018 15:33:26 +0300, Alexander Kuzmenkov wrote in <5142559a-82e6-b3e4-d6ed-8fd2d240c...@postgrespro.ru> > On 08/09/2018 10:33 AM, Kyotaro HORIGUCHI wrote: > > > > - Since I'm not sure unlink is signal-handler safe on all > >supported platforms, I moved unlink() call out of >

Re: Reopen logfile on SIGHUP

On 08/09/2018 10:33 AM, Kyotaro HORIGUCHI wrote: - Since I'm not sure unlink is signal-handler safe on all supported platforms, I moved unlink() call out of checkLogrotateSignal() to SysLoggerMain, just before rotating log file. Which platforms specifically do you have in mind?

Re: Reopen logfile on SIGHUP

Hello. At Tue, 7 Aug 2018 16:36:34 +0300, Alexander Kuzmenkov wrote in > I think the latest v4 patch addresses the concerns raised > upthread. I'm marking the commitfest entry as RFC. Thank you, but it is forgetting pg_ctl --help output. I added it and moved logrotate entry in docs just

Re: Reopen logfile on SIGHUP

I think the latest v4 patch addresses the concerns raised upthread. I'm marking the commitfest entry as RFC. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Reopen logfile on SIGHUP

Here is a documentation update from Liudmila Mantrova. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 4a68ec3..5bd7b45 100644 ---

Re: Reopen logfile on SIGHUP

On 04/25/2018 05:57 PM, Sergei Kornilov wrote: Attached file is empty. My bad, here is the correct file. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index

Re: Reopen logfile on SIGHUP

Hello Something was wrong? Attached file is empty. regards, Sergei

Re: Reopen logfile on SIGHUP

On 04/24/2018 06:09 AM, Kyotaro HORIGUCHI wrote: It seems that the additional description needs to be meld into this at the first place? And some caveat may be needed on failure cases. That's right. I applied your diff and rewrote these paragraphs, adding some words about the possible loss

Re: Reopen logfile on SIGHUP

At Fri, 20 Apr 2018 21:51:49 +0300, Alexander Kuzmenkov wrote in > On 04/16/2018 05:54 AM, Kyotaro HORIGUCHI wrote: > > We can provide a new command "pg_ctl logrotate" to hide the > > details. (It cannot be

Re: Reopen logfile on SIGHUP

On 04/16/2018 05:54 AM, Kyotaro HORIGUCHI wrote: We can provide a new command "pg_ctl logrotate" to hide the details. (It cannot be executed by root, though.) I like this approach. I looked at the patch and changed some things: - cleaned up the error messages - moved checkLogrotateSignal to

Re: Reopen logfile on SIGHUP

At Thu, 12 Apr 2018 17:23:42 +0300, Alexander Kuzmenkov wrote in > On 11.04.2018 00:00, Tom Lane wrote: > > So we need a mechanism that's narrowly targeted > > to reopening the logfile, without SIGHUP'ing the

Re: Reopen logfile on SIGHUP

On 11.04.2018 00:00, Tom Lane wrote: So we need a mechanism that's narrowly targeted to reopening the logfile, without SIGHUP'ing the entire database. We can send SIGUSR1 to the syslogger process. To make its pid easier to find out, it can be published in "$PGDATA/logging_collector.pid", as

Re: Reopen logfile on SIGHUP

On 04/11/2018 12:00 AM, Tom Lane wrote: Alexander Kuzmenkov writes: Syslogger does already rotate logs properly on SIGHUP under some conditions, so we can just change this to unconditional rotation. Probably some people wouldn't want their logs to be rotated on

Re: Reopen logfile on SIGHUP

Alexander Kuzmenkov writes: > Syslogger does already rotate logs properly on SIGHUP under some > conditions, so we can just change this to unconditional rotation. > Probably some people wouldn't want their logs to be rotated on SIGHUP, > so we could also add a GUC

Re: Reopen logfile on SIGHUP

El 10/04/18 a las 22:40, Robert Haas escribió: Having said that, I'm not averse to providing a solution if it's robust, not too invasive and doesn't break other use-cases. So far we've not seen a patch that meets those conditions. Fair enough. Syslogger does already rotate logs properly

Re: Reopen logfile on SIGHUP

On Tue, Apr 10, 2018 at 3:17 PM, Tom Lane wrote: > We, as in the core project, are not shipping it. +1 for what JD said on that subject. > I'm also unclear > on why you want to exclude "fix the RPM packaging" as a reasonable > solution. Mostly because the complaint was

Re: Reopen logfile on SIGHUP

On 04/10/2018 12:17 PM, Tom Lane wrote: Robert Haas writes: On Tue, Feb 27, 2018 at 6:12 PM, Tom Lane wrote: IOW, I think a fair response to this is "if you're using logrotate with Postgres, you're doing it wrong". Well, the original post says

Re: Reopen logfile on SIGHUP

Robert Haas writes: > On Tue, Feb 27, 2018 at 6:12 PM, Tom Lane wrote: >> IOW, I think a fair response to this is "if you're using logrotate with >> Postgres, you're doing it wrong". > Well, the original post says that this is how the PGDG RPMs are

Re: Reopen logfile on SIGHUP

On Tue, Feb 27, 2018 at 6:12 PM, Tom Lane wrote: > IOW, I think a fair response to this is "if you're using logrotate with > Postgres, you're doing it wrong". Well, the original post says that this is how the PGDG RPMs are doing it on Debian/Ubuntu. I wonder if that's due to

Re: Reopen logfile on SIGHUP

Hi Anastasia, On 3/28/18 1:46 PM, David Steele wrote: > On 2/27/18 8:54 PM, Michael Paquier wrote: >> On Tue, Feb 27, 2018 at 05:52:20PM -0500, Tom Lane wrote: >>> It already does treat SIGUSR1 as a log rotation request. Apparently >>> the point of this patch is that some people don't find that

Re: Reopen logfile on SIGHUP

On 2/27/18 8:54 PM, Michael Paquier wrote: > On Tue, Feb 27, 2018 at 05:52:20PM -0500, Tom Lane wrote: >> It already does treat SIGUSR1 as a log rotation request. Apparently >> the point of this patch is that some people don't find that easy enough >> to use, which is fair, because finding out

Re: Reopen logfile on SIGHUP

If there is already SIGUSR1 for logfile reopening then shouldn`t postmaster watch for it? Postmaster PID is easy to obtain. On 02/28/2018 01:32 AM, Greg Stark wrote: On 27 February 2018 at 14:41, Anastasia Lubennikova wrote: Small patch in the attachment

Re: Reopen logfile on SIGHUP

On Tue, Feb 27, 2018 at 05:52:20PM -0500, Tom Lane wrote: > It already does treat SIGUSR1 as a log rotation request. Apparently > the point of this patch is that some people don't find that easy enough > to use, which is fair, because finding out the collector's PID from > outside isn't very

Re: Reopen logfile on SIGHUP

"David G. Johnston" writes: > On Tue, Feb 27, 2018 at 4:12 PM, Tom Lane wrote: >> IOW, I think a fair response to this is "if you're using logrotate with >> Postgres, you're doing it wrong". That was of some use back before we >> spent so much

Re: Reopen logfile on SIGHUP

On 2018-02-27 16:20:28 -0700, David G. Johnston wrote: > On Tue, Feb 27, 2018 at 4:12 PM, Tom Lane wrote: > > > IOW, I think a fair response to this is "if you're using logrotate with > > Postgres, you're doing it wrong". That was of some use back before we > > spent so much

Re: Reopen logfile on SIGHUP

On Tue, Feb 27, 2018 at 4:12 PM, Tom Lane wrote: > IOW, I think a fair response to this is "if you're using logrotate with > Postgres, you're doing it wrong". That was of some use back before we > spent so much sweat on the syslogger, but it's not a reasonable setup > today.

Re: Reopen logfile on SIGHUP

Andres Freund writes: > On 2018-02-27 22:32:41 +, Greg Stark wrote: >> On 27 February 2018 at 14:41, Anastasia Lubennikova >> wrote: >>> Small patch in the attachment implements logfile reopeninig on SIGHUP. >> HUP will cause Postgres to

Re: Reopen logfile on SIGHUP

Greg Stark writes: > On 27 February 2018 at 14:41, Anastasia Lubennikova > wrote: >> Small patch in the attachment implements logfile reopeninig on SIGHUP. >> It only affects the file accessed by logging collector, which name you can >> check with

Re: Reopen logfile on SIGHUP

On 2018-02-27 22:32:41 +, Greg Stark wrote: > On 27 February 2018 at 14:41, Anastasia Lubennikova > wrote: > > > Small patch in the attachment implements logfile reopeninig on SIGHUP. > > It only affects the file accessed by logging collector, which name you can

Re: Reopen logfile on SIGHUP

On 27 February 2018 at 14:41, Anastasia Lubennikova wrote: > Small patch in the attachment implements logfile reopeninig on SIGHUP. > It only affects the file accessed by logging collector, which name you can > check with pg_current_logfile(). HUP will cause

Re: Reopen logfile on SIGHUP

Anastasia Lubennikova writes: > Large percentage of postgres installations, for example PGDG packages > for Debian/Ubuntu, assume by default that log management will be > handled by extrernals tools such as logrotate. > > Unfortunately such tools have no way to tell

Reopen logfile on SIGHUP

false; + + /* Reopen last logfiles on SIGHUP */ + if (last_file_name != NULL) + { +fclose(syslogFile); +syslogFile = logfile_open(last_file_name, "a", false); +ereport(LOG, + (errmsg("Reopen current logfile on SIGHUP"))); + } + + if (last_csv_file_name