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
> > > Windows
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 64-
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
> minor
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 ver
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
> > renamed,
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, K
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 Wi
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
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
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
> >
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? unlink
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 abov
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
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
--- a/doc/src/sgml/maintenance.sgm
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 4a
Hello
Something was wrong? Attached file is empty.
regards, Sergei
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 of
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 executed by root, though.)
>
> I like this approach.
Thanks. I found that the SIGUSR1
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 po
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 entire database.
>
> We can send SIGUSR1 to the syslogger process. To make its pid ea
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
s
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 SIGHUP,
so we could also add a G
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 to control this. Please see th
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 on
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 about the *Debian* packag
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 that this is how the PGDG RPMs are doing
it on
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 doing
> it on Debian/Ubuntu. I wonder if that'
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 some Debian/Ubuntu
p
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 e
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 the
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 implements logfile reopeninig on SIG
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 easy.
"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 sweat on the syslogger, but it's not a reasonable se
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 sweat on the syslogg
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.
>
A couple of weeks
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 reload its config files. That seems like a
>> fine tim
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 pg_current_logfile().
> HUP will cause Postgres
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
> > check with pg_current_logf
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 Postgres to reload its config files.
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 postgres to reopen log
> file
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 postgres to reopen log file
after rotation
and forced to use copy-t
41 matches
Mail list logo
