Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)
Дата
Msg-id CA+TgmoaBYa_WDSFhZA6sPYVnBWH_vwqpXcy3iA93oqaecj2p7A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)
Список pgsql-hackers
On Mon, Jan 22, 2018 at 7:05 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On error, workers should be terminated.  What kind of problem do you
> have in mind?

Hmm.  Yeah, I guess that makes sense.  If the only thing you can do is
fetch from the cursor -- and you have to make sure to lock down
protocol messages as well as SQL commands -- and if any error kills
the workers -- then I guess this might be workable.  However, I think
there are still problems.  Say the worker hits an error while the
leader is idle; how do we report the error?  It's a protocol version
for the leader to send an unsolicited ErrorResponse, which is why we
have to use FATAL rather than ERROR in various places for recovery
conflicts, query cancellation, etc.

Also, if you're OK with not being able to do anything except fetch
from the cursor until you reach the end, then couldn't you just issue
the query without the cursor and use PQsetSingleRowMode?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: MCV lists for highly skewed distributions
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Temporary tables prevent autovacuum, leading to XID wraparound