Re: Suggestion to add --continue-client-on-abort option to pgbench
| От | Fujii Masao |
|---|---|
| Тема | Re: Suggestion to add --continue-client-on-abort option to pgbench |
| Дата | |
| Msg-id | CAHGQGwGHqwD+wvuyDSsee6b80wxj6P3=QbBRfhDMxap43yd8sg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Suggestion to add --continue-client-on-abort option to pgbench (Chao Li <li.evan.chao@gmail.com>) |
| Ответы |
Re: Suggestion to add --continue-client-on-abort option to pgbench
|
| Список | pgsql-hackers |
On Tue, Nov 11, 2025 at 11:49 AM Chao Li <li.evan.chao@gmail.com> wrote: > I just did more tests on both pipeline mode and non-pipeline mode, I think the main purpose of discardAvailableResults()is to drain results for pipeline mode. In non-pipeline mode, a NULL res indicates no more resultto read; while in pipeline mode, when a pipeline is aborted, either a valid result or NULL could still be returned,thus we need to wait until pipeline state switch to PQ_PIPELINE_OK. From this perspective, the current inline commentis correct, but I feel it’s not clear enough. Thanks for working on this! After reconsidering, I think the main goal here is to determine whether the error causes a connection failure after it occurs. If we can read and discard results without PQstatus() becoming CONNECTION_BAD either until the end (in non-pipeline mode) or until the first sync point after an error (in pipeline mode), that means the connection is still alive, and processing can continue when --continue-on-error is specified. The current function comments don’t mention this purpose enough, so seems they should be updated to clarify that. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: