On Sun, Mar 26, 2017 at 3:34 AM, Tom Lane <t...@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/
system_defined_fn_update.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
