Re: OOM in libpq and infinite loop with getCopyStart()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: OOM in libpq and infinite loop with getCopyStart()
Дата
Msg-id 19913.1458620167@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: OOM in libpq and infinite loop with getCopyStart()  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: OOM in libpq and infinite loop with getCopyStart()  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Mon, Mar 21, 2016 at 10:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> It is very difficult to believe that this is a good idea:
>> 
>> --- a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
>> +++ b/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
>> @@ -445,6 +445,7 @@ libpqrcv_PQexec(const char *query)
>>          if (PQresultStatus(lastResult) == PGRES_COPY_IN ||
>>              PQresultStatus(lastResult) == PGRES_COPY_OUT ||
>>              PQresultStatus(lastResult) == PGRES_COPY_BOTH ||
>> +            PQresultStatus(lastResult) == PGRES_FATAL_ERROR ||
>>              PQstatus(streamConn) == CONNECTION_BAD)
>>             break;
>> 
>> I mean, why would it be a good idea to blindly skip over fatal errors?

> I think it is not about skipping the FATAL error, rather to stop trying to
> get further results on FATAL error.

If the code already includes "lost the connection" as a case to break on,
I'm not quite sure why "got a query error" is not.  Maybe that PQstatus
check is broken too, but it doesn't seem like this patch makes it more so.
        regards, tom lane



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Relax requirement for INTO with SELECT in pl/pgsql
Следующее
От: Pavel Stehule
Дата:
Сообщение: parallel aggregation - Numeric is unsupported?