Re: [COMMITTERS] pgsql: Improve access to parallel queryfrom procedural languages.
От | Robert Haas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Improve access to parallel queryfrom procedural languages. |
Дата | |
Msg-id | CA+TgmoZpM-6pDfj_ONHPpARmr7ZhgvGBCQYo9T2kpvP2Gtfx7w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Improve access to parallel query from procedural languages. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql: Improve access to parallel queryfrom procedural languages.
Re: [COMMITTERS] pgsql: Improve access to parallel query from procedural languages. |
Список | 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 по дате отправления: