On Sun, Nov 20, 2016 at 8:53 AM, Andreas Seltenreich <seltenreich@gmx.de> wrote:
> the following query appears to reliably crash parallel workers on master
> as of 0832f2d.
>
> --8<---------------cut here---------------start------------->8---
> set max_parallel_workers_per_gather to 2;
> set force_parallel_mode to 1;
>
> select subq.context from pg_settings,
> lateral (select context from pg_opclass limit 1) as subq
> limit 1;
> --8<---------------cut here---------------end--------------->8---
>
> Backtrace of a worker below.
Based on the backtrace, I wonder if this might be a regression
introduced by Tom's recent commit
9a00f03e479c2d4911eed5b4bd1994315d409938, "Improve speed of aggregates
that use array_append as transition function.", which adds additional
cases where expanded datums can be used. In theory, a value passed
from the leader to the workers ought to have gone through
datumSerialize() which contains code to flatten expanded
representations, but it's possible that code is broken, or maybe the
problematic code path is something else altogether. I'm just
suspicious about the fact that the failure is in
MakeExpandedObjectReadOnlyInternal().
Then again, that might just be a coincidence. The other thing that's
weird here is that the Datum being passed is apparently a NULL
pointer, which neither MakeExpandedObjectReadOnly() nor
MakeExpandedObjectReadOnlyInternal() are prepared to deal with. I
don't know whether it's wrong for a NULL pointer to occur here in the
first place or whether it's wrong for those functions not to be able
to deal with it if it does.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company