Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)
Date
Msg-id CA+TgmoaBYa_WDSFhZA6sPYVnBWH_vwqpXcy3iA93oqaecj2p7A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: MCV lists for highly skewed distributions
Next
From: Robert Haas
Date:
Subject: Re: Temporary tables prevent autovacuum, leading to XID wraparound