On Wed, Feb 7, 2018 at 9:47 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jan 22, 2018 at 7:05 AM, Amit Kapila <amit.kapil...@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? >
I guess workers need to wait till leader become active and processes the error message. > 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? > I think there is a lot of cursor usage via plpgsql in which it could be useful. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
