Re: libpq async duplicate error results

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq async duplicate error results
Date: 2022-05-06 13:49:28
Message-ID: de57761c-b99b-3435-b0a6-474c72b1149a@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I took another look at this. The output from the test program at the
beginning of the thread is now (master branch):

command = SELECT 'before';
result 1 status = PGRES_TUPLES_OK
error message = ""

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 = "server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
"

command = SELECT 'after';
PQsendQuery() error: 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.
no connection to the server

It appears the "after" query is getting the error message from the
previous cycle somehow.

The output in PG14 and PG13 is:

command = SELECT 'after';
PQsendQuery() error: no connection to the server

Is the change intended or do we need to think about more tweaking?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-05-06 13:51:09 Re: make MaxBackends available in _PG_init
Previous Message Matheus Alcantara 2022-05-06 13:43:39 Re: Trying to add more tests to gistbuild.c