I wrote:
> What is happening is that this bit in PQsendQueryStart is deciding
> not to clear the message buffer because conn->cmd_queue_head isn't
> NULL:
> /*
> * If this is the beginning of a query cycle, reset the error state.
> * However, in pipeline mode with something already q
Peter Eisentraut writes:
> I took another look at this. The output from the test program at the
> beginning of the thread is now (master branch):
> ...
> command = SELECT 'after';
> PQsendQuery() error: FATAL: terminating connection due to administrator
> command
> server closed the connection
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
erro
Actually ... it now seems to me that there's live bugs in the
interaction between pipeline mode and error-buffer clearing.
Namely, that places like PQsendQueryStart will unconditionally
clear the buffer even though we may be in the middle of a pipeline
sequence, and the buffer might hold an error t
I wrote:
> However ... in the wake of 618c16707, I wonder if we should consider
> an alternative definition, which is to NOT clear errorMessage when
> starting a new pipelined query. (That would be this patch minus
> the addition to pqPipelineProcessQueue.) Thanks to 618c16707,
> the returned err
Alvaro Herrera writes:
> On 2022-Feb-07, Tom Lane wrote:
>> I see that PQgetResult does a hacky "resetPQExpBuffer(&conn->errorMessage)"
>> in between pipelined queries. It seems like if there are real usability
>> issues in this area, they probably come from that not being well placed.
>> In part
Andres Freund writes:
> On 2022-02-16 20:28:02 -0500, Tom Lane wrote:
>> Uh ... then we'd have to cast away the const to do free().
> I was just thinking of
> if ((const PGresult *) res == &OOM_result)
Oh, I see. Sure, can do it like that.
regards, tom lane
Hi,
On 2022-02-16 20:28:02 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-02-16 18:51:37 -0500, Tom Lane wrote:
> >> + /* Also, do nothing if the argument is OOM_result */
> >> + if (res == unconstify(PGresult *, &OOM_result))
> >> + return;
>
> > Wouldn't it make more sens
Andres Freund writes:
> On 2022-02-16 18:51:37 -0500, Tom Lane wrote:
>> +/* Also, do nothing if the argument is OOM_result */
>> +if (res == unconstify(PGresult *, &OOM_result))
>> +return;
> Wouldn't it make more sense to make res const, rather than unconstifying
> &OOM_resu
Hi,
On 2022-02-16 18:51:37 -0500, Tom Lane wrote:
> This seems workable, and you'll notice it fixes the duplicated text
> in the test case Andres was worried about.
Cool.
I find it mildly scary that we didn't have any other tests verifying the libpq
side of connection termination. Seems like we
I wrote:
>>> An idea that I don't have time to pursue right now is to track
>>> how much of conn->errorMessage has been read out by PQgetResult,
>>> and only report newly-added text in later PQgetResult calls of
>>> a series, while PQerrorMessage would continue to report the
>>> whole thing. Buffe
On 2022-Feb-07, Tom Lane wrote:
> In any case, the particular example we're looking at here is connection
> loss, which is not something that should greatly concern us as far as
> pipeline semantics are concerned, because you're not getting any more
> pipelined results anyway if that happens. In
[ cc'ing Alvaro for pipeline questions ]
Fabien COELHO writes:
>> It is annoying that some of the text is duplicated in the second
>> report, but in the end that's cosmetic, and I'm not sure we can
>> improve it without breaking other things. In particular, we
>> can't just think about what come
Hello Tom,
I concur with Fabien's analysis: we report the FATAL message from
the server during the first PQgetResult, and then the second call
discovers that the connection is gone and reports "server closed
the connection unexpectedly". Those are two independent events
(in libpq's view anywa
Peter Eisentraut writes:
> Tom, you worked on reorganzing the error message handling in libpq in
> PostgreSQL 14 (commit ffa2e4670123124b92f037d335a1e844c3782d3f). Any
> thoughts on this?
Ah, sorry, I'd not noticed this thread.
I concur with Fabien's analysis: we report the FATAL message from
Tom, you worked on reorganzing the error message handling in libpq in
PostgreSQL 14 (commit ffa2e4670123124b92f037d335a1e844c3782d3f). Any
thoughts on this?
On 25.01.22 09:32, Peter Eisentraut wrote:
This issue was discovered by Fabien in the SHOW_ALL_RESULTS thread. I'm
posting it here s
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 connecti
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 clo
This issue was discovered by Fabien in the SHOW_ALL_RESULTS thread. I'm
posting it here separately, because I think it ought to be addressed in
libpq rather than with a workaround in psql, as proposed over there.
When using PQsendQuery() + PQgetResult() and the server crashes during
the exe
19 matches
Mail list logo
