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 CAHGQGwH_cEZA9n7AgvpErkR-kw5hi=RKhvR3vR8-OL_hojGqwA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Suggestion to add --continue-client-on-abort option to pgbench  (Yugo Nagata <nagata@sraoss.co.jp>)
Ответы Re: Suggestion to add --continue-client-on-abort option to pgbench
Список pgsql-hackers
On Wed, Nov 12, 2025 at 6:34 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:
> I've attached an updated patch.

Thanks for updating the patch!

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

+ /*
+ * If a PGRES_PIPELINE_SYNC is followed by something other than
+ * PGRES_PIPELINE_SYNC or NULL, another PGRES_PIPELINE_SYNC will
+ * eventually follow.
+ */

LGTM. I'd like to append "Reset received_sync to false to wait for
it." into this comment.


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

Would it be better to move this status check right after PQgetResult()
so that connection failures can be detected regardless of what result
it returns?

+ pg_log_error("client %d aborted: the backend died while rolling back
the failed transaction after",

The trailing “after” seems unnecessary.

Since there's no guarantee the backend actually died in this case,
it might be better to use something like "client %d aborted while rolling back
the transaction after an error; perhaps the backend died while processing"
which matches the wording used under CSTATE_WAIT_ROLLBACK_RESULT
in advanceConnectionState().

Regards,

--
Fujii Masao



В списке pgsql-hackers по дате отправления: