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 the non-I/O-error case,
> 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 particular, I wonder why that's done with the pqPipelineProcessQueue
> call in the PGASYNC_IDLE stanza, yet not with the pqPipelineProcessQueue
> call in the PGASYNC_READY stanza (where we're returning a PIPELINE_SYNC
> result). It kinda looks to me like maybe pqPipelineProcessQueue
> ought to have the responsibility for doing that, rather than having
> two out of the three call sites do it. Also it would seem more natural
> to associate it with the reinitialization that happens inside
> pqPipelineProcessQueue.
Yeah, I agree that the placement of error message reset in pipelined
libpq is more ad-hoc to the testing I was doing than carefully
principled. I didn't test changing it, but on a quick look your
proposed change seems reasonable to me.
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"Pensar que el espectro que vemos es ilusorio no lo despoja de espanto,
sólo le suma el nuevo terror de la locura" (Perelandra, C.S. Lewis)
