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
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 |