Hi,
On 2020-12-16 18:12:39 +0900, Fujii Masao wrote:
> - /* Wait to be signaled by UnpinBuffer() */
> + /*
> + * Wait to be signaled by UnpinBuffer().
> + *
> + * We assume that only UnpinBuffer() and the timeout requests
> established
> + * above can wake us up here.
On 2020/12/16 18:12, Fujii Masao wrote:
On 2020/12/16 16:24, Kyotaro Horiguchi wrote:
At Tue, 15 Dec 2020 23:10:28 +0900, Fujii Masao
wrote in
I pushed the following two patches.
- v1-use-standard-SIGHUP-hanlder-in-syslogger-process.patch
-
On 2020/12/16 16:24, Kyotaro Horiguchi wrote:
At Tue, 15 Dec 2020 23:10:28 +0900, Fujii Masao
wrote in
I pushed the following two patches.
- v1-use-standard-SIGHUP-hanlder-in-syslogger-process.patch
- v1-use-MyLatch-and-standard-SIGHUP-handler-in-startup-process.patch
As I told in other
At Tue, 15 Dec 2020 23:10:28 +0900, Fujii Masao
wrote in
> > I pushed the following two patches.
> > - v1-use-standard-SIGHUP-hanlder-in-syslogger-process.patch
> > - v1-use-MyLatch-and-standard-SIGHUP-handler-in-startup-process.patch
>
> As I told in other thread [1], I'm thinking to revert
On 2020/11/04 18:06, Fujii Masao wrote:
On 2020/10/29 15:21, Fujii Masao wrote:
On 2020/10/07 11:30, Bharath Rupireddy wrote:
On Tue, Oct 6, 2020 at 11:41 AM Bharath Rupireddy
wrote:
On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao wrote:
+1 Or it's also ok to make each patch
On 2020/11/27 16:47, Bharath Rupireddy wrote:
On Fri, Nov 27, 2020 at 12:26 PM Fujii Masao
wrote:
> > When I read the patch again, I found that, with the patch, the shutdown
> > of worker_spi causes to report the following FATAL message.
> >
> > FATAL: terminating connection
On Fri, Nov 27, 2020 at 12:26 PM Fujii Masao
wrote:
>
> > > > When I read the patch again, I found that, with the patch, the shutdown
> > > > of worker_spi causes to report the following FATAL message.
> > > >
> > > > FATAL: terminating connection due to administrator command
> > > >
>
On 2020/11/27 12:13, Bharath Rupireddy wrote:
On Wed, Nov 25, 2020 at 8:08 PM Bharath Rupireddy
mailto:bharath.rupireddyforpostg...@gmail.com>> wrote:
>
> > When I read the patch again, I found that, with the patch, the shutdown
> > of worker_spi causes to report the following FATAL
On Wed, Nov 25, 2020 at 8:08 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
>
> > When I read the patch again, I found that, with the patch, the shutdown
> > of worker_spi causes to report the following FATAL message.
> >
> > FATAL: terminating connection due to
On 2020/11/27 0:15, Bharath Rupireddy wrote:
On Thu, Nov 26, 2020 at 7:37 PM Fujii Masao wrote:
What do you mean by normal shutdown of bgworker? Is it that bgworker has exited
successfully with exit code 0 or for some reason with exit code other than 0?
Or is it when the postmaster is
On Thu, Nov 26, 2020 at 7:37 PM Fujii Masao wrote:
>
> > What do you mean by normal shutdown of bgworker? Is it that bgworker has
> > exited successfully with exit code 0 or for some reason with exit code
> > other than 0? Or is it when the postmaster is shutdown normally?
> >
> > IIUC, when a
On 2020/11/25 23:38, Bharath Rupireddy wrote:
On Wed, Nov 25, 2020 at 3:29 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
>
> On 2020/11/20 19:33, Bharath Rupireddy wrote:
> > On Wed, Nov 18, 2020 at 5:52 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>
On Wed, Nov 25, 2020 at 3:29 PM Fujii Masao
wrote:
>
> On 2020/11/20 19:33, Bharath Rupireddy wrote:
> > On Wed, Nov 18, 2020 at 5:52 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
> > >
> > > > handle_sigterm() and die() are similar except that die() has extra
> > > >
On 2020/11/20 19:33, Bharath Rupireddy wrote:
On Wed, Nov 18, 2020 at 5:52 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
>
> > handle_sigterm() and die() are similar except that die() has extra
> > handling(below) for exiting immediately when waiting for input/command
> >
On Wed, Nov 18, 2020 at 5:52 PM Fujii Masao
wrote:
>
> > handle_sigterm() and die() are similar except that die() has extra
> > handling(below) for exiting immediately when waiting for input/command
> > from the client.
> > /*
> > * If we're in single user mode, we want to quit
On 2020/11/17 21:18, Bharath Rupireddy wrote:
Thanks Craig!
On Fri, Oct 23, 2020 at 9:37 AM Craig Ringer
wrote:
src/test/modules/test_shm_mq/worker.c appears to do the right thing the wrong
way - it has its own custom handler instead of using die() or
SignalHandlerForShutdownRequest().
Thanks Craig!
On Fri, Oct 23, 2020 at 9:37 AM Craig Ringer
wrote:
>
> src/test/modules/test_shm_mq/worker.c appears to do the right thing the wrong
> way - it has its own custom handler instead of using die() or
> SignalHandlerForShutdownRequest().
>
handle_sigterm() and die() are similar
On 2020/11/13 20:24, Bharath Rupireddy wrote:
On Thu, Nov 12, 2020 at 10:06 AM Fujii Masao
wrote:
Thanks for the analysis! I pushed the patch.
Thanks! Since we are replacing custom SIGHUP and SIGTERM handlers with
standard ones, how about doing the same thing in worker_spi.c? I
posted a
On Thu, Nov 12, 2020 at 10:06 AM Fujii Masao
wrote:
>
> Thanks for the analysis! I pushed the patch.
>
Thanks! Since we are replacing custom SIGHUP and SIGTERM handlers with
standard ones, how about doing the same thing in worker_spi.c? I
posted a patch previously [1] in this mail thread. If it
On 2020/11/10 21:30, Bharath Rupireddy wrote:
On Tue, Nov 10, 2020 at 3:04 PM Fujii Masao wrote:
The main reason for having SetLatch() in
SignalHandlerForConfigReload() is to wake up the calling process if
waiting in WaitLatchOrSocket() or WaitLatch() and reload the new
config file and
Hi,
Attaching a patch that replaces custom signal handlers for SIGHUP and
SIGTERM in worker_spi.c.
Thoughts?
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
From a212163b64bc3ab4b8d4493e6d53f32979e3e9bf Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy
Date: Tue, 10
On Tue, Nov 10, 2020 at 3:04 PM Fujii Masao wrote:
>
> >> The main reason for having SetLatch() in
> >> SignalHandlerForConfigReload() is to wake up the calling process if
> >> waiting in WaitLatchOrSocket() or WaitLatch() and reload the new
> >> config file and use the reloaded config variables.
On 2020/11/10 16:17, Kyotaro Horiguchi wrote:
At Sat, 7 Nov 2020 19:31:21 +0530, Bharath Rupireddy
wrote in
The main reason for having SetLatch() in
SignalHandlerForConfigReload() is to wake up the calling process if
waiting in WaitLatchOrSocket() or WaitLatch() and reload the new
config
At Sat, 7 Nov 2020 19:31:21 +0530, Bharath Rupireddy
wrote in
> The main reason for having SetLatch() in
> SignalHandlerForConfigReload() is to wake up the calling process if
> waiting in WaitLatchOrSocket() or WaitLatch() and reload the new
> config file and use the reloaded config variables.
On Fri, Nov 6, 2020 at 11:00 PM Fujii Masao wrote:
>
> >> I'm not quite sure to replace all the places in the walreceiver
> >> process, for instance in WalRcvForceReply() we are using spinlock to
> >> acquire the latch pointer and . Others may have better thoughts on
> >> this.
> >
> > The
On 2020/11/05 12:12, Kyotaro Horiguchi wrote:
At Wed, 4 Nov 2020 21:16:29 +0530, Bharath Rupireddy
wrote in
On Wed, Nov 4, 2020 at 2:36 PM Fujii Masao wrote:
Regarding other two patches, I think that it's better to use MyLatch
rather than MyProc->procLatch or walrcv->latch in
At Wed, 4 Nov 2020 21:16:29 +0530, Bharath Rupireddy
wrote in
> On Wed, Nov 4, 2020 at 2:36 PM Fujii Masao
> wrote:
> >
> > Regarding other two patches, I think that it's better to use MyLatch
> > rather than MyProc->procLatch or walrcv->latch in WaitLatch() and
> > ResetLatch(), like other
On Wed, Nov 4, 2020 at 2:36 PM Fujii Masao wrote:
>
> Regarding other two patches, I think that it's better to use MyLatch
> rather than MyProc->procLatch or walrcv->latch in WaitLatch() and
> ResetLatch(), like other code does. Attached are the updated versions
> of the patches. Thought?
>
+1
On 2020/10/29 15:21, Fujii Masao wrote:
On 2020/10/07 11:30, Bharath Rupireddy wrote:
On Tue, Oct 6, 2020 at 11:41 AM Bharath Rupireddy
wrote:
On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao wrote:
+1 Or it's also ok to make each patch separately.
Anyway, thanks!
Thanks. +1 to have
On 2020/10/07 11:30, Bharath Rupireddy wrote:
On Tue, Oct 6, 2020 at 11:41 AM Bharath Rupireddy
wrote:
On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao wrote:
+1 Or it's also ok to make each patch separately.
Anyway, thanks!
Thanks. +1 to have separate patches. I will post two separate
On Wed, Oct 7, 2020 at 8:39 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Wed, Oct 7, 2020 at 8:00 AM Bharath Rupireddy
> wrote:
> >
> > On Tue, Oct 6, 2020 at 11:41 AM Bharath Rupireddy
> > wrote:
> > >
> > > On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao <
>
On Wed, Oct 7, 2020 at 8:00 AM Bharath Rupireddy
wrote:
>
> On Tue, Oct 6, 2020 at 11:41 AM Bharath Rupireddy
> wrote:
> >
> > On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao
> > wrote:
> > >
> > > +1 Or it's also ok to make each patch separately.
> > > Anyway, thanks!
> > >
> >
> > Thanks. +1 to
On Tue, Oct 6, 2020 at 11:41 AM Bharath Rupireddy
wrote:
>
> On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao
> wrote:
> >
> > +1 Or it's also ok to make each patch separately.
> > Anyway, thanks!
> >
>
> Thanks. +1 to have separate patches. I will post two separate patches
> for autoprewarm and
On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao wrote:
>
> >>
> >> Probably we can also replace sigHupHandler() in syslogger.c with
> >> SignalHandlerForConfigReload()? This would be separate patch, though.
> >>
> >
> > +1 to replace sigHupHandler() with SignalHandlerForConfigReload() as
> > the
On Mon, Oct 05, 2020 at 11:34:05PM +0900, Fujii Masao wrote:
> ISTM that we can also replace StartupProcSigHupHandler() in startup.c
> with SignalHandlerForConfigReload() by making the startup process use
> the general shared latch instead of its own one. POC patch attached.
> Thought?
That looks
On 2020/10/06 1:18, Bharath Rupireddy wrote:
On Mon, Oct 5, 2020 at 8:04 PM Fujii Masao wrote:
On 2020/10/05 19:45, Bharath Rupireddy wrote:
Hi,
Autoprewarm module is using it's own SIGHUP(apw_sigterm_handler, got_sigterm)
and SIGTERM(apw_sighup_handler, got_sighup) handlers which are
On Mon, Oct 5, 2020 at 8:04 PM Fujii Masao wrote:
>
> On 2020/10/05 19:45, Bharath Rupireddy wrote:
> > Hi,
> >
> > Autoprewarm module is using it's own SIGHUP(apw_sigterm_handler,
> > got_sigterm) and SIGTERM(apw_sighup_handler, got_sighup) handlers which are
> > similar to standard signal
On 2020/10/05 19:45, Bharath Rupireddy wrote:
Hi,
Autoprewarm module is using it's own SIGHUP(apw_sigterm_handler, got_sigterm)
and SIGTERM(apw_sighup_handler, got_sighup) handlers which are similar to
standard signal handlers(except for a difference [1]). Isn't it good to remove
them and
Hi,
Autoprewarm module is using it's own SIGHUP(apw_sigterm_handler,
got_sigterm) and SIGTERM(apw_sighup_handler, got_sighup) handlers which are
similar to standard signal handlers(except for a difference [1]). Isn't it
good to remove them and use standard SignalHandlerForConfigReload and
39 matches
Mail list logo
