Re: libpq async duplicate error results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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 15:47:34
Message-ID: 2942076.1651852054@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 queued, the error
> * buffer belongs to that command and we shouldn't clear it.
> */
> if (newQuery && conn->cmd_queue_head == NULL)
> pqClearConnErrorState(conn);

> So apparently the fault is with the pipelined-query logic. I'm
> not sure what cleanup step is missing though.

I experimented with the attached patch, which is based on the idea
that clearing the command queue is being done in entirely the wrong
place. It's more appropriate to do it where we drop unsent output
data, ie in pqDropConnection not pqDropServerData. The fact that
it was jammed into the latter without any commentary doesn't do much
to convince me that that placement was thought about carefully.

This fixes the complained-of symptom and still passes check-world.
However, I wonder whether cutting the queue down to completely empty
is the right thing. Why is the queue set up like this in the first
place --- that is, why don't we remove an entry the moment the
command is sent? I also wonder whether pipelineStatus ought to
get reset here. We aren't resetting asyncStatus here, so maybe it's
fine, but I'm not quite sure.

regards, tom lane

Attachment Content-Type Size
reset-libpq-command-queue-more-correctly-wip.patch text/x-diff 1.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-05-06 15:52:45 Re: Possible corruption by CreateRestartPoint at promotion
Previous Message Nathan Bossart 2022-05-06 15:27:11 Re: make MaxBackends available in _PG_init