On Thu, Feb 8, 2018 at 9:04 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> I guess workers need to wait till leader become active and processes
> the error message.
So if you kill a worker, it doesn't die but sits there waiting for
someone to run a command in the leader? That sounds terrible.
>> 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?
>
> I think there is a lot of cursor usage via plpgsql in which it could be useful.
I don't see how. If you can't do anything but fetch from the cursor
while the cursor is open, then you can't go start doing things in
plpgsql code either. If you allow plpgsql code to run during that
time, then it can do arbitrary stuff which breaks the design
assumptions around parallel mode, like calling parallel-unsafe
functions or trying to do transaction control or running DML.
The whole point here is that the parallel-mode stuff is only designed
to cleanly error out in cases that we think we can hit during the
course of executing a query. In other cases, it may elog(), Assert(),
crash, give wrong answers, etc. As soon as you let parallel-mode
survive beyond the context of a query, you've opened a huge can of
worms which you will not be easily able to shut. If we restrict what
you can do outside of a query to a very narrow set of operations, then
it might survive, but "execute arbitrary plpgsql code" is not a narrow
set of operations.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company