Thread: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-R rate)options together.
[BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-R rate)options together.
From
nuko yokohama
Date:
Hi.
I attempted to make the following measurements using PostgreSQL 9.6.0 pgbench on CentOS 7.
$ pgbench -P 5 -R 400 -C -S -r -c 4 -T 30 bench -U postgres
However, this benchmark did not work properly.
* I refer to pg_stat_activity, but no connection from pgbench to PostgreSQL.
* pgbench does not stop even after the time specified by the -T option elapses.
It operates normally when only the -C option or only the -R option is specified.
In the PostgreSQL document, It is not described that "these two options can not be specified at the same time ".
Is this a problem of pgbench?
Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-Rrate) options together.
From
Fabien COELHO
Date:
> It operates normally when only the -C option or only the -R option is > specified. > > In the PostgreSQL document, It is not described that "these two options > can not be specified at the same time ". Is this a problem of pgbench? Yes, indeed there is. Thanks for the report. Option -C is seldom used and tested. -- Fabien. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-Rrate) options together.
From
Fabien COELHO
Date:
>> It operates normally when only the -C option or only the -R option is >> specified. >> >> In the PostgreSQL document, It is not described that "these two options can >> not be specified at the same time ". Is this a problem of pgbench? > > Yes, indeed there is. Thanks for the report. Option -C is seldom used and > tested. The problem is already fixed in head. Looking at git log, it was unclear to guess which change fixed that... After another reading, I got it in one, it has been fixed by Heikki restructuring patch 12788ae49e1933f463bc59a6efe46c4a01701b76 which has no vocation to be backpatched to prior versions... The bug is that prior to --rate doCustom was always disconnect/reconnect without exiting, but with rate it returns if it has to wait. However threadRun test whether there is a connection before recalling doCustom, so it was never called. This is exactly the kind of unmanageable state combination that refactoring has cleaned up. Attached a small patch which fixes the issue, I think, in 9.6. Fixing it raised another issue wrt to some stats under -C, that I fixed as well. -- Fabien. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs