Re: [COMMITTERS] pgsql: Improve access to parallel queryfrom procedural languages. - Mailing list pgsql-hackers

From Rafia Sabih
Subject Re: [COMMITTERS] pgsql: Improve access to parallel queryfrom procedural languages.
Date
Msg-id CAOGQiiOPQJ-KQokWLRSBQ=oYh-6w0TuWGZEgDwOzDagdhJXBCA@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Mar 26, 2017 at 3:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> It doesn't seem to be a platform-specific problem: I can duplicate the
>> failure here by applying same settings mandrill uses, ie build with
>> -DRANDOMIZE_ALLOCATED_MEMORY and set force_parallel_mode = regress.
>
> Oh ... scratch that: you don't even need -DRANDOMIZE_ALLOCATED_MEMORY.
> For some reason I just assumed that any parallelism-related patch
> would have been tested with force_parallel_mode = regress.  This one
> evidently was not.
>
>                         regards, tom lane
>

This is caused because trigger related functions are marked safe and
using global variables, hence when executed in parallel are giving
incorrect  output. Attached patch fixes this. I have modified only
those functions that are showing incorrect behaviour in the regress
output and checked regression test with force_parallel_mode = regress
and all testcases are passing now.

This concerns me that should we be checking all the system defined
functions once again if they are actually parallel safe...?

-- 
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: WIP: Faster Expression Processing v4
Next
From: Amit Kapila
Date:
Subject: Re: [POC] A better way to expand hash indexes.