Re: [BUGS] Segfault 11 on PG10 with max_parallel_workers_per_gather>3 - Mailing list pgsql-bugs

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@postgresql.org>  2017-10-14 00:23:28
> Committer: Robert Haas <rhaas@postgresql.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@empirica-systeme.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@postgresql.org>  2017-10-14 00:23:28
> Committer: Robert Haas <rhaas@postgresql.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@empirica-systeme.de
phone  +49 7071 6392922
mobile +49 176 40 38 9559

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



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs