On Wed, Dec 7, 2016 at 12:30 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Dec 6, 2016 at 1:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>> Done. >> >> The comment seems quite confused now: >> >> * If a tuple count was supplied or data is being written to relation, we >> * must force the plan to run without parallelism, because we might exit >> * early. >> >> Exit early is exactly what we *won't* do if writing to an INTO rel, so >> I think this will confuse future readers. I think it should be more like >> >> * If a tuple count was supplied, we must force the plan to run without >> * parallelism, because we might exit early. Also disable parallelism >> * when writing into a relation, because [ uh, why exactly? ] >> >> Considering that the writing would happen at top level of the executor, >> and hence in the parent process, it's not actually clear to me why the >> second restriction is there at all: can't we write tuples to a rel even >> though they came from a parallel worker? In any case, the current wording >> of the comment is a complete fail at explaining this. > > Oops. You're right. [ uh, why exactly? ] -> no database changes > whatsoever are allowed while in parallel mode. (This restriction > might be lifted someday, but right now we're stuck with it.) >
Attached patch changes the comment based on above suggestions. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
fix_comment_parallel_mode_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
