On Mon, Mar 27, 2017 at 9:25 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Mar 27, 2017 at 1:48 AM, Rafia Sabih >> <rafia.sa...@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. > >> 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')? > > Color me confused, but under what circumstances would triggers get > executed by a parallel worker at all? I thought we did not allow > updating queries to be parallelized.
Right, we don't. But if the updating query fires a trigger, and the trigger runs an SQL statement that is itself safe for parallelism, *that* statement could be run in parallel. In almost all cases it won't make sense because triggers aren't likely to contain SQL statements that are expensive enough to justify running them in parallel, but there's no a priori reason to disallow it. (And, indeed, I think this commit and the subsequent breakage shows the value of making sure that parallel query is allowed in as many places as possible. Running the regression tests with force_parallel_mode=regress is the best automated tool we have to find cases where functions are labeled as being more safe than they actually are, but those tests only try inserting the invisible single-copy Gather node in cases where parallel query is allowable at all.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers