On Thu, Feb 8, 2018 at 9:04 AM, Amit Kapila <amit.kapil...@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
