Re: libpq async duplicate error results

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: libpq async duplicate error results
Дата
Msg-id f9c3ea51-ae67-358b-6e50-f52ed8142bf8@enterprisedb.com
обсуждение исходный текст
Ответ на Re: libpq async duplicate error results  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
On 26.01.22 14:52, Fabien COELHO wrote:
> 
>> command = SELECT pg_terminate_backend(pg_backend_pid());
>> result 1 status = PGRES_FATAL_ERROR
>> error message = "FATAL:  terminating connection due to administrator 
>> command
>> "
>> result 2 status = PGRES_FATAL_ERROR
>> error message = "FATAL:  terminating connection due to administrator 
>> command
>> server closed the connection unexpectedly
>>     This probably means the server terminated abnormally
>>     before or while processing the request.
>> "
> 
>> Also, why are there multiple results being generated in the first place?
> 
> My interpretation is that the first message is a close message issued by 
> the server before actually severing the connection, and the second 
> message is generated by libpq when it notices that the connection has 
> been closed, so there is some sense in having to results to report these 
> two consecutive errors, and the question might be about when the buffer 
> should be reset.

I see.  If we stipulate for a moment that getting two results is what we 
want here, I see a conceptual problem.  Users of PQexec() don't care 
whether the error message they are ultimately getting is a concatenation 
of two messages from two internal results (old behavior) or just an 
appropriately accumulated message from the last internal result (new 
behavior).  But users of PQgetResult() don't have a principled way to 
deal with this anymore.  They can't just ignore one or the other result, 
because they could after all be two separate errors from two separate 
commands.  So the only proper behavior is to show all errors from all 
results.  But that results in this misbehavior because the last error 
message must include the messages from the previous messages in order to 
accommodate PQexec() users.




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

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error
Следующее
От: Sergey Dudoladov
Дата:
Сообщение: Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint?