On Mon, Mar 27, 2017 at 9:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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.
>
>> 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
