From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg11.1: dsa_area could not attach to segment |
Date: | 2019-02-12 05:33:31 |
Message-ID: | CAEepm=2k=DXA56KEeRq05c2xSpdM5Kw4i-GG_MtzMXcnOkEnDA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 12, 2019 at 4:27 PM Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Tue, Feb 12, 2019 at 4:01 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > On Mon, Feb 11, 2019 at 08:43:14PM -0600, Justin Pryzby wrote:
> > > I have a suspicion that this doesn't happen if
> > > parallel_leader_participation=off.
> >
> > I think this is tentatively confirmed..I ran 20 loops for over 90 minutes with
> > no crash when parallel_leader_participation=off.
> >
> > On enabling parallel_leader_participation, crash within 10min.
>
> That's quite interesting. I wonder if it's something specific about
> the leader's behaviour, or if it's just because it takes one more
> process to hit the bad behaviour on your system.
. o O ( is there some way that getting peppered with signals from the
shm tuple queue machinery could break something here? )
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-02-12 06:24:31 | Re: First-draft release notes for next week's releases |
Previous Message | Thomas Munro | 2019-02-12 05:27:01 | Re: pg11.1: dsa_area could not attach to segment |