On Mon, Sep 7, 2015 at 1:40 PM, Michael Paquier <michael.paquier@gmail.com>
wrote:
>
> On Sat, Sep 5, 2015 at 9:45 PM, Amit Kapila <amit.kapila16@gmail.com>
wrote:
> >
>
> So, I think that the right approach would be to leave immediately
> pqParseInput3 should an error happen, switching asyncStatus to leave
> the loop in PQgetResult.
Sure, if you think that works, then do it that way.
> This seems as well to work correctly with
> PGRES_COPY_BOTH (I emulated failures with pg_basebackup and errors
> were caught up correctly. This brings back of course the introduction
> of a new flag PGASYNC_FATAL
I think we should try not to introduce this new flag, as that is not merely
a
flag, but rather a state in query-execution state machine. Now if we
introduce
a new error state into that state-machine, then it doesn't seem like a good
idea to do that only for some of the paths and doing it for all other paths
is a call for somewhat larger verification cycle (to see if it works in all
paths
as previously).
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
