| 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: | Whole Thread | Raw Message | 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 |