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

From Robert Haas
Subject Re: [COMMITTERS] pgsql: Improve access to parallel queryfrom procedural languages.
Date
Msg-id CA+TgmoZpM-6pDfj_ONHPpARmr7ZhgvGBCQYo9T2kpvP2Gtfx7w@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>)
Responses Re: [COMMITTERS] pgsql: Improve access to parallel queryfrom procedural languages.  (Rafia Sabih <rafia.sabih@enterprisedb.com>)
Re: [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Mar 27, 2017 at 1:48 AM, Rafia Sabih
<rafia.sabih@enterprisedb.com> 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
> 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.

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')?

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

It's certainly possible that we've made mistakes in other places, too.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Kang Yuzhe
Date:
Subject: On How To Shorten the Steep Learning Curve Towards PG Hacking...
Next
From: Robert Haas
Date:
Subject: Re: Parallel bitmap heap scan