From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Jonathan Rudenberg <jonathan(at)titanous(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andreas Seltenreich <seltenreich(at)gmx(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [sqlsmith] Unpinning error in parallel worker |
Date: | 2018-04-20 04:42:41 |
Message-ID: | CAEepm=0awU3+3mdpBTREjSFg1Km1Lx3ikO5NF-fML4tirQMBmw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 18, 2018 at 11:43 AM, Jonathan Rudenberg
<jonathan(at)titanous(dot)com> wrote:
> On Tue, Apr 17, 2018, at 19:31, Thomas Munro wrote:
>> On Wed, Apr 18, 2018 at 11:01 AM, Jonathan Rudenberg
>> <jonathan(at)titanous(dot)com> wrote:
>> > Yep, I think I know approximately what it looked like, I've attached a lightly redacted plan. All of the hung queries were running some variant of this plan as far as I can tell.
>>
>> Hmm, that isn't a parallel query. I was expecting to see "Gather" and
>> "Parallel" in there.
>
> Oops, I'm really sorry about that. I only have the first part of the hung queries, and there are a few variants. Here's one that's parallel.
I spent some time trying to reproduce this failure without any luck,
using query plans similar to your Gather plan fragment, and using some
test harness code for the allocator stuff in isolation.
I had an idea that (1) freeing a large object that releases and unpins
a segment in one backend and then (2) freeing it again in another
backend (illegally) might produce this effect with sufficiently bad
luck. I'm still trying to reproduce that without any success, but I
get other kinds of failures which I think you'd be seeing too if that
hunch were right. Still looking...
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-04-20 05:47:50 | Re: Should we add GUCs to allow partition pruning to be disabled? |
Previous Message | Michael Paquier | 2018-04-20 03:37:08 | Re: Re: Is there a memory leak in commit 8561e48? |