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

From Amit Langote
Subject Re: Server crashed with dense_rank on partition table.
Date
Msg-id 2fa356c8-c3c7-27f8-f50b-ff0cfb39e5c4@lab.ntt.co.jp
Whole thread Raw
In response to Re: Server crashed with dense_rank on partition table.  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2018/07/05 9:40, Andres Freund wrote:
> 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!

Thank you.

Regards,
Amit



pgsql-hackers by date:

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