Re: Fix around conn_duration in pgbench

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fix around conn_duration in pgbench
Date: 2021-06-14 08:57:07
Message-ID: alpine.DEB.2.22.394.2106141011100.1338009@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Yugo-san,

> TState has a field called "conn_duration" and this is, the comment says,
> "cumulated connection and deconnection delays". This value is summed over
> threads and reported as "average connection time" under -C/--connect.
> If this options is not specified, the value is never used.


> However, I found that conn_duration is calculated even when -C/--connect
> is not specified, which is waste. SO we can remove this code as fixed in
> the attached patch.

I'm fine with the implied code simplification, but it deserves a comment.

> In addition, deconnection delays are not cumulated even under -C/--connect
> in spite of mentioned in the comment. I also fixed this in the attached patch.

I'm fine with that, even if it only concerns is_connect. I've updated the
command to work whether now is initially set or not. I'm unsure whether
closing a pg connection actually waits for anything, so probably the
impact is rather small anyway. It cannot be usefully measured when
!is_connect, because thread do that when then feel like it, whereas on
connection we can use barriers to have something which makes sense.

Also, there is the issue of connection failures: the attached version adds
an error message and exit for initial connections consistently.
This is not done with is_connect, though, and I'm unsure what we should
really do.


Attachment Content-Type Size
pgbench-conn-duration-2.patch text/x-diff 3.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-06-14 09:17:44 Re: SQLSTATE for replication connection failures
Previous Message Amit Kapila 2021-06-14 08:48:34 Re: Failure in subscription test