Re: parallel mode and parallel contexts

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: parallel mode and parallel contexts
Дата
Msg-id 553D979F.8080608@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: parallel mode and parallel contexts  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: parallel mode and parallel contexts  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Следующее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)