On Sun, Apr 26, 2015 at 9:57 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > 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.
That sounds like a bug in the assess-parallel-safety patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
