On 2015-04-22 AM 04:14, Robert Haas wrote: > > We should check IsParallelWorker() for operations that are allowed in > the master during parallel mode, but not allowed in the workers - e.g. > the master can scan its own temporary relations, but its workers > can't. We should check IsInParallelMode() for operations that are > completely off-limits in parallel mode - i.e. writes. > > We use ereport() where we expect that SQL could hit that check, and > elog() where we expect that only (buggy?) C code could hit that check. >
By the way, perhaps orthogonal to the basic issue Alvaro and you are discussing here - when playing around with (parallel-mode + parallel-safety + parallel heapscan + parallel seqscan), I'd observed (been a while since) that if you run a CREATE TABLE AS ... SELECT and the SELECT happens to use parallel scan, the statement as a whole fails because the top level statement (CTAS) is not read-only. So, only way to make CTAS succeed is to disable seqscan; which may require some considerations in reporting to user to figure out. I guess it happens because the would-be parallel leader of the scan would also be the one doing DefineRelation() DDL. Apologies if this has been addressed since. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
