From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "a(dot)kozhemyakin" <a(dot)kozhemyakin(at)postgrespro(dot)ru> |
Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add Pipelining support in psql |
Date: | 2025-04-22 00:06:20 |
Message-ID: | aAbdfKU2ZWeuAnIG@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 21, 2025 at 03:22:28PM +0900, Michael Paquier wrote:
> Anyway, I don't think that there is much we can do under a
> PGRES_FATAL_ERROR in this code path when discarding the pipe results.
> As far as I can tell, the server has failed the query suddenly and the
> whole pipeline flow is borked. The best thing that I can think of is
> to discard all the results while decrementing the counters, then let
> psql complain about that like in the attached. I've added two tests
> in TAP, as these trigger a FATAL in the backend so we cannot use the
> normal SQL route, so as we have some coverage.
>
> @Anthonin: Any thoughts or comments, perhaps? A second opinion would
> be welcome here.
While considering more ways to test this patch, I've recalled that
injection points that issue a FATAL in the backend to emulate the
original failure with more query patterns can provide more coverage,
and the discard cleanup is showing stable enough as presented in the
patch. I am wondering if we could not be smarter with the handling of
the counters, but I really doubt that there is much more we can do
under a PGRES_FATAL_ERROR.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2025-04-22 00:07:55 | Re: [PATCH] Documentation: Fix minor grammatical and formatting issues |
Previous Message | Jacob Champion | 2025-04-21 23:19:06 | Re: [PoC] Federated Authn/z with OAUTHBEARER |