Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-R rate) options together.

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-R rate) options together.
Date: 2017-01-25 19:58:31
Message-ID: alpine.DEB.2.20.1701252057440.2871@lancre
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers


Repost from bugs.

--
Fabien.

---------- Forwarded message ----------
Date: Wed, 25 Jan 2017 18:59:45 +0100 (CET)
From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: nuko yokohama <nuko(dot)yokohama(at)gmail(dot)com>
Cc: PostgreSQL Bugs List <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-R
rate) options together.

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

Attachment Content-Type Size
pgbench-CR-bug-1.patch text/x-diff 731 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2017-01-25 20:02:21 Re: pg_ls_dir & friends still have a hard-coded superuser check
Previous Message Andres Freund 2017-01-25 19:52:38 Re: lseek/read/write overhead becomes visible at scale ..