Re: Segfault 11 on PG10 with max_parallel_workers_per_gather>3

Hi

Am 08.11.2017 um 14:24 schrieb Dilip Kumar:
> By looking at the plan it seems like the issue what got fixed in below
commit.
>>
> Author: Robert Haas <rhaas(at)postgresql(dot)org> 2017-10-14 00:23:28
> Committer: Robert Haas <rhaas(at)postgresql(dot)org> 2017-10-14 00:35:14
> Parent: d48bf6a94d295c3779c6af4df118d95a6606192f (Fix AggGetAggref()
> so it won't lie to aggregate final functions.)
> Child: cb591fcbfbba1df6fda1839ece53665e85e491e3 (Restore nodeAgg.c's
> ability to check for improperly-nested aggregates.)
> Branch: remotes/origin/REL_10_STABLE
> Follows: REL_10_0
> Precedes: REL_10_1
>
> Fix possible crash with Parallel Bitmap Heap Scan.
>
> If a Parallel Bitmap Heap scan's chain of leftmost descendents
> includes a BitmapOr whose first child is a BitmapAnd, the prior coding
> would mistakenly create a non-shared TIDBitmap and then try to perform
> shared iteration.
>
> Report by Tomas Vondra. Patch by Dilip Kumar.

Do I understand it correctly, that that fix would be released with 10.1
tomorrow (according to https://www.postgresql.org/developer/roadmap/)
and I could then test it?

Steve

Am 08.11.2017 um 14:24 schrieb Dilip Kumar:
> On Wed, Oct 25, 2017 at 5:46 PM, Stefan Tzeggai
> <tzeggai(at)empirica-systeme(dot)de> wrote:
>
>> "Finalize Aggregate (cost=186411.37..186411.38 rows=1 width=8)"
>> " -> Gather (cost=186410.95..186411.36 rows=4 width=8)"
>> " Workers Planned: 4"
>> " -> Partial Aggregate (cost=185410.95..185410.96 rows=1 width=8)"
>> " -> Parallel Bitmap Heap Scan on
>> as_20171025_20170930_ut78777 rt (cost=12058.69..185353.14 rows=23121
>> width=0)"
>> " Recheck Cond: (((oadr_gkz = ANY
>> ('{2000000,5111000,5314000,5315000,5334002,5515000,6411000,6412000,7315000,8111000,8221000,9162000,9184119,11000000,14612000}'::integer[]))
>> AND (objekttyp_grob = 1)) OR (oadr_gkz = 2000000))"
>> " Filter: ((oart_zwangsversteigerung_janein IS NULL)
>> AND (((oadr_gkz = ANY
>> ('{2000000,5111000,5314000,5315000,5334002,5515000,6411000,6412000,7315000,8111000,8221000,9162000,9184119,11000000,14612000}'::integer[]))
>> AND (objekttyp_grob = 1 (...)"
>> " -> BitmapOr (cost=12058.69..12058.69 rows=94046
>> width=0)"
>> " -> BitmapAnd (cost=11726.20..11726.20
>> rows=76321 width=0)"
>> " -> Bitmap Index Scan on
>
>
> By looking at the plan it seems like the issue what got fixed in below commit.
>
> Author: Robert Haas <rhaas(at)postgresql(dot)org> 2017-10-14 00:23:28
> Committer: Robert Haas <rhaas(at)postgresql(dot)org> 2017-10-14 00:35:14
> Parent: d48bf6a94d295c3779c6af4df118d95a6606192f (Fix AggGetAggref()
> so it won't lie to aggregate final functions.)
> Child: cb591fcbfbba1df6fda1839ece53665e85e491e3 (Restore nodeAgg.c's
> ability to check for improperly-nested aggregates.)
> Branch: remotes/origin/REL_10_STABLE
> Follows: REL_10_0
> Precedes: REL_10_1
>
> Fix possible crash with Parallel Bitmap Heap Scan.
>
> If a Parallel Bitmap Heap scan's chain of leftmost descendents
> includes a BitmapOr whose first child is a BitmapAnd, the prior coding
> would mistakenly create a non-shared TIDBitmap and then try to perform
> shared iteration.
>
> Report by Tomas Vondra. Patch by Dilip Kumar.
>

--
empirica-systeme GmbH
Stefan Tzeggai
Brunsstr. 31
72074 Tübingen
email tzeggai(at)empirica-systeme(dot)de
phone +49 7071 6392922
mobile +49 176 40 38 9559

"Wer nichts zu verbergen hat, braucht auch keine Hose!"