Re: Infinite loop in pgbench when running COPY command

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Infinite loop in pgbench when running COPY command
Date: 2025-10-02 08:26:57
Message-ID: aN43URxzMCI2B-I-@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 01, 2025 at 11:25:00AM +0200, Anthonin Bonnefoy wrote:
> Currently, pgbench processes a copy response as unexpected and will
> move to the error loop. However, PQgetResult will alway return an
> empty result when there's no async result through getCopyResult,
> leading to an infinite loop in the error handling as res will never be
> NULL.
>
> This patch forcefully exits the copy state with PQendcopy before
> moving to the error handler, avoiding the infinite loop.

Fun. It seems like nobody has ever tested this scenario, even for a
COPY TO. Why did you try that? Did you have a benchmark scenario in
mind?

+ case PGRES_COPY_IN:
+ case PGRES_COPY_OUT:
+ case PGRES_COPY_BOTH:
+ pg_log_error("COPY is not supported in pgbench, aborting");
+
+ /*
+ * We need to exit copy state. Otherwise, PQgetResult will
+ * always return an empty PGresult from getCopyResult, leading
+ * to an infinite loop during error cleanup
+ */
+ PQendcopy(st->con);
+ goto error;

That sounds like a good choice to just fail for the time being, all
these result types don't seem to work (quickly checked). If somebody
wants to support this case, we could always sort it out, but I am
ready to bet that the odds are in the favor of doing nothing.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2025-10-02 08:49:27 Re: Eager aggregation, take 3
Previous Message Nazir Bilal Yavuz 2025-10-02 06:58:36 Re: split func.sgml to separated individual sgml files