| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Rintaro Ikeda <ikedarintarof(at)oss(dot)nttdata(dot)com>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "slpmcf(at)gmail(dot)com" <slpmcf(at)gmail(dot)com>, "boekewurm+postgres(at)gmail(dot)com" <boekewurm+postgres(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Subject: | Re: Suggestion to add --continue-client-on-abort option to pgbench |
| Date: | 2025-11-10 02:06:35 |
| Message-ID: | 7BF486E2-E9D3-4F52-A643-C9FEA4CE5F92@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Nov 7, 2025, at 17:33, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Fri, Nov 7, 2025 at 9:07 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>> If you put this explanation to the inline comment, things would get clearer. But based on this explanation, I just got the other doubt. When a pipeline is aborted, res is NULL, but we still stay in the for loop, PQClear(res) will do nothing, then the “for” loop is similar to an empty loop, would that lead to a high CPU usage? From this perspective, when pipeline is aborted, while waiting for PIPELINE_SYNC, adding a tiny sleep might be better.
>
> You're concerned about cases where the server response is delayed,
> causing the pipeline status to take time to reach PIPELINE_SYNC, right?
> In that situation, since discardAvailableResults() waits on PQgetResult(),
> it shouldn't enter a busy loop, correct?
>
>
>> I will back to work next Monday, then I will try to run a test and reproduce the scenario of pipeline abort.
>
> I plan to commit the patch soon, but let's keep discussing and
> investigating the case you mentioned afterward!
>
I just did a test. In the test, I inserted a tuple with the same primary key so that the inserts fails by the unique key constraint which breaks the pipeline, and some random select statements followed. And I added some debug messages in discardAvailableResults(), which showed me that the function will discard rest of statements’ results until \endpipeline. As there are anyway limited number of statements before \endpipeline, my concern is actually not valid. So, now I am good with this patch.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2025-11-10 02:30:31 | Re: Add tests for object size limits of injection points |
| Previous Message | Tomas Vondra | 2025-11-10 01:26:07 | Re: Changing the state of data checksums in a running cluster |