Re: PQexec() hangs on OOM

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: PQexec() hangs on OOM
Дата
Msg-id 552427FC.6060302@iki.fi
обсуждение исходный текст
Ответ на Re: PQexec() hangs on OOM  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: PQexec() hangs on OOM  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-bugs
On 04/07/2015 09:18 AM, Michael Paquier wrote:
> @@ -143,7 +143,11 @@ PQmakeEmptyPGresult(PGconn *conn, ExecStatusType status)
>
>      result = (PGresult *) malloc(sizeof(PGresult));
>      if (!result)
> +    {
> +        printfPQExpBuffer(&conn->errorMessage,
> +                          libpq_gettext("out of memory\n"));
>          return NULL;
> +    }
>
>      result->ntups = 0;
>      result->numAttributes = 0;

That's not cool, because PQmakeEmptyPGresult may be called with conn ==
NULL. In general, I'm a bit wary of changing PQmakeEmptyResult so that
it sets the error message. Will have to check all the callers carefully
to see if that would upset any of them. And it might be called by
applications too.

> I have noticed as well that getCopyStart() in fe-protocol3.c needs to
> be made a little bit smarter to make the difference between an OOM and
> the not-enough-data type of problem.

Yeah. getParamDescription still has the issue, with your patch.

> This problem has a low probability to happen in the field, and no
> people complained about that as well, so I think that patching only
> HEAD is adapted.

As long as the patch applies easily, I don't see much reason to not
backpatch.

- Heikki

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #12992: Failure to start: too many private dirs demanded
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: BUG #12992: Failure to start: too many private dirs demanded