Re: [sqlsmith] Parallel worker crash on seqscan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andreas Seltenreich <seltenreich(at)gmx(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [sqlsmith] Parallel worker crash on seqscan
Date: 2016-11-21 17:29:05
Message-ID: 23874.1479749345@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Nov 21, 2016 at 12:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It seems like maybe searching for individual Params is the wrong thing.
>> Why are we allowing it to generate a parameterized Gather path at all?
>> Given the lack of any way to transmit runtime param values to the worker,
>> I can't see how that would ever work.

> Hmm, so you're thinking it could be the job of generate_gather_paths()
> to make sure we don't do that?

Actually, the Gather path *isn't* parameterized. The problem here is
that we're planning an unflattened subquery, and the only thing that
is parallel-unsafe is that there is an outer Param in its toplevel tlist,
and we're somehow deciding that we can stick that unsafe tlist into (and
beneath) the Gather node. So something rotten in that area, but I've not
quite found it yet.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-11-21 17:29:41 Re: delta relations in AFTER triggers
Previous Message Robert Haas 2016-11-21 17:17:14 Re: delta relations in AFTER triggers