On Sat, Nov 17, 2018 at 2:27 PM Thomas Munro
wrote:
> Thanks for the review.
Pushed.
--
Thomas Munro
http://www.enterprisedb.com
On Sat, Nov 17, 2018 at 5:56 AM Tom Lane wrote:
> Thomas Munro writes:
> > [ 0001-Add-WL_EXIT_ON_PM_DEATH-pseudo-event-v4.patch ]
>
> I took a quick look through this. I have no objection to the idea of
> letting the latch infrastructure do the proc_exit(1), but I'm wondering
> why this is in th
Thomas Munro writes:
> [ 0001-Add-WL_EXIT_ON_PM_DEATH-pseudo-event-v4.patch ]
I took a quick look through this. I have no objection to the idea of
letting the latch infrastructure do the proc_exit(1), but I'm wondering
why this is in the thread that it's in. Is there any remaining connection
to
At Fri, 26 Oct 2018 14:13:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20181026.141351.09076928.horiguchi.kyot...@lab.ntt.co.jp>
> Thank you for the fix.
>
> At Tue, 23 Oct 2018 17:26:37 +1300, Thomas Munro
> wrote in
>
> > On Thu, Sep 6, 2018 at 9:57 PM Kyotaro HORIGUCHI
> >
Thank you for the fix.
At Tue, 23 Oct 2018 17:26:37 +1300, Thomas Munro
wrote in
> On Thu, Sep 6, 2018 at 9:57 PM Kyotaro HORIGUCHI
> wrote:
> > And don't we need a description about this restriction in the
> > function comment?
>
> Ok, added.
Thank you. It looks good.
> While rebasing
On Thu, Sep 6, 2018 at 9:57 PM Kyotaro HORIGUCHI
wrote:
> In sysloger.c, cur_flags is (just set but) no longer used.
Right. Fixed.
> ===
> In latch.c,
>
> - The parentheses around the symbols don't seem to be needed.
> | (wakeEvents & (WL_EXIT_ON_PM_DEATH)) != 0 ||
> | (wake
Ugrrr! PLEASE ignore this! It's not wrong at all.
2018年9月6日(木) 18:58 Kyotaro HORIGUCHI :
> - The following assertion looks contradicting to the comment.
> |/* Postmaster-managed callers must handle postmaster death somehow. */
> |Assert(!IsUnderPostmaster ||
> | (wakeEvents & (W
At Sun, 2 Sep 2018 07:04:19 +1200, Thomas Munro
wrote in
> > > # Is it intentional that the patch doesn't touch pgstat.c?
> >
> > Yes. pgstat.c still uses WL_POSTMASTER_DEATH because it does
> > something special: it calls pgstat_write_statsfiles() before it exits.
Mmm. Exactly..
> Rebased.
On Thu, Jul 19, 2018 at 11:51 PM Thomas Munro
wrote:
> On Thu, Jul 19, 2018 at 10:30 PM, Kyotaro HORIGUCHI
> > Yeah. That seems good. Couldn't we reuse prepared WaitEventSet in
> > other places? For example PgstatCollectorMain has the same
> > characteristics, where WaitLatchOrSocket is used with
On Thu, Jul 19, 2018 at 10:30 PM, Kyotaro HORIGUCHI
wrote:
>> Hmm. Why wait any longer? The cluster is broken. Is there some
>> correctness reason to defer shutdown in any of these places?
>
> Well, please don't get me wrong. I don't object to backends' exit
> on postmaster death, rather I'm fo
At Thu, 19 Jul 2018 16:58:30 +1200, Thomas Munro
wrote in
> On Wed, Jul 18, 2018 at 8:30 PM, Kyotaro HORIGUCHI
> wrote:
> > At Wed, 18 Jul 2018 14:02:47 +1200, Thomas Munro
> > wrote in
> >
> >> Here are some of the places I had to add WL_EXIT_ON_PM_DEATH:
> >> gather_readnext(), shm_mq_se
On Wed, Jul 18, 2018 at 8:30 PM, Kyotaro HORIGUCHI
wrote:
> At Wed, 18 Jul 2018 14:02:47 +1200, Thomas Munro
> wrote in
>
>> Here are some of the places I had to add WL_EXIT_ON_PM_DEATH:
>> gather_readnext(), shm_mq_send_bytes(), shm_mq_receive_bytes(),
>> shm_mq_wait_internal(), ProcSleep(),
Hello.
At Wed, 18 Jul 2018 14:02:47 +1200, Thomas Munro
wrote in
> On Sat, Jul 14, 2018 at 5:34 AM, Heikki Linnakangas wrote:
> > On 18/04/18 09:55, Thomas Munro wrote:
> >> Here's a draft patch that does that. One contentious question is:
> >> should you have to opt *in* to auto-exit-on-pos
On Sat, Jul 14, 2018 at 5:34 AM, Heikki Linnakangas wrote:
> On 18/04/18 09:55, Thomas Munro wrote:
>> Here's a draft patch that does that. One contentious question is:
>> should you have to opt *in* to auto-exit-on-postmaster death? Andres
>> opined that you should. I actually think it's not s
On 18/04/18 09:55, Thomas Munro wrote:
Here's a draft patch that does that. One contentious question is:
should you have to opt *in* to auto-exit-on-postmaster death? Andres
opined that you should. I actually think it's not so bad if you don't
have to do that, and instead have to opt out. I t
On Wed, Apr 18, 2018 at 6:55 PM, Thomas Munro
wrote:
> Here's a draft patch that does that.
Here's a better one (the previous version could read past the end of
the occurred_events array).
--
Thomas Munro
http://www.enterprisedb.com
0001-Exit-by-default-if-postmaster-dies-v2.patch
Description
Hi,
I'd like to disentangle two related topics. For "I want
PostmasterIsAlive() to go faster using signals on platforms that can
support that", please see over here:
https://www.postgresql.org/message-id/flat/7261eb39-0369-f2f4-1bb5-62f3b6083...@iki.fi#7261eb39-0369-f2f4-1bb5-62f3b6083...@iki.fi
On Wed, Apr 11, 2018 at 12:47 PM, Thomas Munro
wrote:
> On Wed, Apr 11, 2018 at 12:26 PM, Andres Freund wrote:
>> On 2018-04-11 12:17:14 +1200, Thomas Munro wrote:
>>> I arrived at this idea via the realisation that the closest thing to
>>> prctl(PR_SET_PDEATHSIG) on BSD-family systems today is
>
On Wed, Apr 11, 2018 at 12:26 PM, Andres Freund wrote:
> On 2018-04-11 12:17:14 +1200, Thomas Munro wrote:
>> I arrived at this idea via the realisation that the closest thing to
>> prctl(PR_SET_PDEATHSIG) on BSD-family systems today is
>> please-tell-my-kqueue-if-this-process-dies. It so happens
Hi,
On 2018-04-11 12:17:14 +1200, Thomas Munro wrote:
> I arrived at this idea via the realisation that the closest thing to
> prctl(PR_SET_PDEATHSIG) on BSD-family systems today is
> please-tell-my-kqueue-if-this-process-dies. It so happens that my
> kqueue patch already uses that instead of the
On Wed, Apr 11, 2018 at 12:03 PM, Andres Freund wrote:
> On 2018-04-11 11:57:20 +1200, Thomas Munro wrote:
>> Then if pgarch_ArchiverCopyLoop() and HandleStartupProcInterrupts()
>> (ie loops without waiting) adopt a prctl(PR_SET_PDEATHSIG)-based
>> approach where available as suggested by Andres[2
Hi,
On 2018-04-11 11:57:20 +1200, Thomas Munro wrote:
> Rebased, but I don't actually like this patch any more. Over in
> another thread[1] I proposed that we should just make exit(1) the
> default behaviour built into latch.c for those cases that don't want
> to do something special (eg SyncRepW
On Tue, Sep 20, 2016 at 11:26 AM, Andres Freund wrote:
> On 2016-09-20 11:07:03 +1200, Thomas Munro wrote:
>> Yeah, I wondered why that was different than the pattern established
>> elsewhere when I was hacking on replication code. There are actually
>> several places where we call PostmasterIsAl
On Tue, Dec 5, 2017 at 5:55 AM, Marco Pfatschbacher
wrote:
> On Thu, Sep 15, 2016 at 04:40:00PM -0400, Tom Lane wrote:
>> I just noticed that kqueue appears to offer a solution to this problem,
>> ie one of the things you can wait for is exit of another process (named
>> by PID, looks like). If t
On Thu, Sep 15, 2016 at 04:40:00PM -0400, Tom Lane wrote:
> Thomas Munro writes:
> > Very interesting. Perhaps that is why NetBSD shows a speedup with the
> > kqueue patch[1] but FreeBSD doesn't. I guess that if I could get the
> > kqueue patch to perform better on large FreeBSD systems, it woul
25 matches
Mail list logo