From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Improve access to parallel query from procedural languages. |
Date: | 2017-03-27 12:24:09 |
Message-ID: | CA+TgmoZpM-6pDfj_ONHPpARmr7ZhgvGBCQYo9T2kpvP2Gtfx7w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Mon, Mar 27, 2017 at 1:48 AM, Rafia Sabih
<rafia(dot)sabih(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-03-27 12:37:34 | pgsql: Pass DSA_ALLOC_HUGE when allocating a shared TIDBitmap. |
Previous Message | Peter Eisentraut | 2017-03-27 12:23:23 | pgsql: Clean up Perl code according to perlcritic |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-03-27 12:28:07 | Re: Parallel bitmap heap scan |
Previous Message | Peter Eisentraut | 2017-03-27 12:23:23 | pgsql: Clean up Perl code according to perlcritic |