Re: Server crashed with dense_rank on partition table. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Server crashed with dense_rank on partition table.
Date
Msg-id 20180705004018.qzfrgt6olezmkl4m@alap3.anarazel.de
Whole thread Raw
In response to Re: Server crashed with dense_rank on partition table.  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Server crashed with dense_rank on partition table.  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
On 2018-07-02 17:14:14 +0900, Amit Langote wrote:
> I studied this a bit and found a bug that's causing the crash.
> 
> The above mentioned commit has this hunk:
> 
> @@ -1309,6 +1311,9 @@ hypothetical_dense_rank_final(PG_FUNCTION_ARGS)
>          PG_RETURN_INT64(rank);
> 
>      osastate = (OSAPerGroupState *) PG_GETARG_POINTER(0);
> +    econtext = osastate->qstate->econtext;
> +    if (!econtext)
> +        osastate->qstate->econtext = econtext =
> CreateStandaloneExprContext();
> 
> In CreateStandloneExprContext(), we have this:
> 
>     econtext->ecxt_per_query_memory = CurrentMemoryContext;
> 
>     /*
>      * Create working memory for expression evaluation in this context.
>      */
>     econtext->ecxt_per_tuple_memory =
>         AllocSetContextCreate(CurrentMemoryContext,
>                               "ExprContext",
>                               ALLOCSET_DEFAULT_SIZES);
> 
> I noticed when debugging the crashing query that CurrentMemoryContext is
> actually per-tuple memory context of some expression context of the
> calling code, which would get reset before getting here again.  So, it's
> wrong of hypothetical_dense_rank_final to call CreateStandloneExprContext
> without first switching to an actual per-query context.
> 
> Attached patch seems to fix the crash.

Thanks, that looks correct. Pushed!

- Andres


pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: peripatus build failures....
Next
From: Larry Rosenman
Date:
Subject: Re: peripatus build failures....