Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

2017-03-29 Thread Robert Haas
On Wed, Mar 29, 2017 at 12:02 AM, Rafia Sabih wrote: > On Tue, Mar 28, 2017 at 9:05 PM, Robert Haas wrote: >> OK, but don't pg_event_trigger_dropped_objects and >> pg_event_trigger_ddl_commands need the same treatment? >> > Done. > I was only

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

2017-03-28 Thread Rafia Sabih
On Tue, Mar 28, 2017 at 9:05 PM, Robert Haas wrote: > OK, but don't pg_event_trigger_dropped_objects and > pg_event_trigger_ddl_commands need the same treatment? > Done. I was only concentrating on the build farm failure cases, otherwise I think more work might be required

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

2017-03-28 Thread Robert Haas
On Mon, Mar 27, 2017 at 11:57 PM, Rafia Sabih wrote: > On Mon, Mar 27, 2017 at 5:54 PM, Robert Haas wrote: >> >> If it's just that they are relying on unsynchronized global variables, >> then it's sufficient to mark them parallel-restricted

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

2017-03-27 Thread Rafia Sabih
On Mon, Mar 27, 2017 at 5:54 PM, Robert Haas wrote: > > If it's just that they are relying on unsynchronized global variables, > then it's sufficient to mark them parallel-restricted ('r'). Do we > really need to go all the way to parallel-unsafe ('u')? > Done. --

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

2017-03-27 Thread Robert Haas
On Mon, Mar 27, 2017 at 9:25 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Mar 27, 2017 at 1:48 AM, Rafia Sabih >> wrote: >>> This is caused because trigger related functions are marked safe and >>> using global

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

2017-03-27 Thread Tom Lane
Robert Haas writes: > On Mon, Mar 27, 2017 at 1:48 AM, Rafia Sabih > wrote: >> This is caused because trigger related functions are marked safe and >> using global variables, hence when executed in parallel are giving >> incorrect output. >

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

2017-03-27 Thread Robert Haas
On Mon, Mar 27, 2017 at 1:48 AM, Rafia Sabih wrote: > 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 >

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

2017-03-26 Thread Rafia Sabih
On Sun, Mar 26, 2017 at 3:34 AM, Tom Lane 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. >

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

2017-03-25 Thread Tom Lane
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

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

2017-03-25 Thread Tom Lane
Robert Haas writes: > Improve access to parallel query from procedural languages. Mandrill has been failing since this patch went in, eg https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill=2017-03-25%2021%3A34%3A08 It doesn't seem to be a platform-specific