On Sun, Apr 26, 2015 at 9:57 PM, Amit Langote
<Langote_Amit_f8@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