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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)
Date: 2018-02-07 16:17:43
Message-ID: CA+TgmoaBYa_WDSFhZA6sPYVnBWH_vwqpXcy3iA93oqaecj2p7A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 22, 2018 at 7:05 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-02-07 16:22:42 Re: Temporary tables prevent autovacuum, leading to XID wraparound
Previous Message Dean Rasheed 2018-02-07 15:58:14 Re: MCV lists for highly skewed distributions