Re: Suggestion to add --continue-client-on-abort option to pgbench - Mailing list pgsql-hackers

From Yugo Nagata
Subject Re: Suggestion to add --continue-client-on-abort option to pgbench
Date
Msg-id 20251112183346.83f98eaa0b5e4674b1735b3f@sraoss.co.jp
Whole thread Raw
In response to Re: Suggestion to add --continue-client-on-abort option to pgbench  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Wed, 12 Nov 2025 00:20:15 +0900
Fujii Masao <masao.fujii@gmail.com> wrote:

> On Tue, Nov 11, 2025 at 10:50 AM Yugo Nagata <nagata@sraoss.co.jp> wrote:
> > I've attached a patch to fix this.
> 
> Thanks for reporting the issue and providing the patch!
> 
> > If a PGRES_PIPELINE_SYNC is followed by something other than PGRES_PIPELINE_SYNC or NULL,
> > it means that another PGRES_PIPELINE_SYNC will eventually follow after some other results.
> > In this case, we should reset the receive_sync flag and continue discarding results.
> 
> Yes.
> 
> + if (res)
> + {
> + received_sync = false;
> + continue;
> 
> Shouldn't we also call PQclear(res) here? For example:

Thank you for your review!
Yes, we need PQclear() here.

I've attached an updated patch.

The comment for the PQpipelineSync() call has been also updated to clarify
why it is necessary.

In addition, I added a connection status check in the loop to avoid an
infinte loop that waiting for PQpipelineSync after a connection failure.

I packed these changes in the same patch, but they can be split into separate
patches.

What do you think?

Regards,
Yugo Nagata

-- 
Yugo Nagata <nagata@sraoss.co.jp>

Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: SQL:2011 Application Time Update & Delete
Next
From: Yugo Nagata
Date:
Subject: Re: Suggestion to add --continue-client-on-abort option to pgbench