Re: Fix around conn_duration in pgbench - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Fix around conn_duration in pgbench
Date
Msg-id alpine.DEB.2.22.394.2106141011100.1338009@pseudo
Whole thread Raw
In response to Fix around conn_duration in pgbench  (Yugo NAGATA <nagata@sraoss.co.jp>)
Responses Re: Fix around conn_duration in pgbench
List 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.

Yep.

> 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.

-- 
Fabien.
Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Failure in subscription test 004_sync.pl
Next
From: Amit Kapila
Date:
Subject: Re: SQLSTATE for replication connection failures