Re: Suggestion to add --continue-client-on-abort option to pgbench

On Thu, 13 Nov 2025 13:14:37 +0800
Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:

>
>
> > On Nov 13, 2025, at 12:02, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> >
> >
> >
> >> On Nov 13, 2025, at 11:47, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> >>
> >> On Thu, Nov 13, 2025 at 11:21 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> >>> I debugged further this morning, and I think I have found the root cause. Ultimately, the problem is not with discardUntilSync(), instead, discardAvailableResults() mistakenly eats PGRES_PIPELINE_SYNC.
> >>
> >> Thanks for debugging!
> >>
> >> Yes, discardAvailableResults() can discard PGRES_PIPELINE_SYNC,
> >> but do you mean that's the root cause of the assertion failure
> >> Nagata-san reported?
> >> Since that failure can occur even in older branches, I was thinking
> >> that newer code
> >> like discardAvailableResults() in master isn't the root cause...
> >>
> >
> > I haven’t debugged with old code, but the old code also discard non-NULL results:
> >
> > ```
> > - do
> > - {
> > - res = PQgetResult(st->con);
> > - PQclear(res);
> > - } while (res);
> > + discardAvailableResults(st);
> > ```
> >
> > Which may also discard the sync message. That’s my guess. I can also debug the old code this afternoon.
> >
>
> I just tried the old code but it didn’t trigger the assert with Yugo’s deadlock scripts.

To trigger a deadlock error, the tables need to have enough rows so that the scan takes some
time. In my environment, about 1,000 rows were enough to cause a deadlock.

Regards,
Yugo Nagata

>
> I did "git reset --hard a3ea5330fcf47390c8ab420bbf433a97a54505d6”, that is the previous commit of “—continue-on-error”. And I ran Yugo’s deadlock scripts, but I didn’t get the assert:
>
> ```
> % pgbench -n --failures-detailed -M extended -j 2 -c 2 -f deadlock.sql -f deadlock2.sql evantest
> pgbench (19devel)
> transaction type: multiple scripts
> scaling factor: 1
> query mode: extended
> number of clients: 2
> number of threads: 2
> maximum number of tries: 1
> number of transactions per client: 10
> number of transactions actually processed: 20/20
> number of failed transactions: 0 (0.000%)
> number of serialization failures: 0 (0.000%)
> number of deadlock failures: 0 (0.000%)
> latency average = 0.341 ms
> initial connection time = 2.637 ms
> tps = 5865.102639 (without initial connection time)
> SQL script 1: deadlock.sql
> - weight: 1 (targets 50.0% of total)
> - 12 transactions (60.0% of total)
> - number of transactions actually processed: 12 (tps = 3519.061584)
> - number of failed transactions: 0 (0.000%)
> - number of serialization failures: 0 (0.000%)
> - number of deadlock failures: 0 (0.000%)
> - latency average = 0.311 ms
> - latency stddev = 0.304 ms
> SQL script 2: deadlock2.sql
> - weight: 1 (targets 50.0% of total)
> - 8 transactions (40.0% of total)
> - number of transactions actually processed: 8 (tps = 2346.041056)
> - number of failed transactions: 0 (0.000%)
> - number of serialization failures: 0 (0.000%)
> - number of deadlock failures: 0 (0.000%)
> - latency average = 0.366 ms
> - latency stddev = 0.364 ms
> ```
>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>