Re: PQexec() hangs on OOM

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: PQexec() hangs on OOM
Date: 2015-09-07 09:45:04
Message-ID: CAA4eK1LHAvJUZTVdV1nuGPXKibqNwV-HPaD8W-axLKXrVdr+Ew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Sep 7, 2015 at 1:40 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:
>
> On Sat, Sep 5, 2015 at 9:45 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2015-09-07 13:41:34 Re: PQexec() hangs on OOM
Previous Message Michael Paquier 2015-09-07 08:10:10 Re: PQexec() hangs on OOM