Re: pgbench small bug fix - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench small bug fix
Date
Msg-id alpine.DEB.2.10.1603041935280.11128@sto
Whole thread Raw
In response to Re: pgbench small bug fix  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pgbench small bug fix
List pgsql-hackers
>> Probably it is possible, but it will sure need more that one little
>> condition to be achieved... I do not think that introducing a non trivial
>> distributed election algorithm involving locks and so would be a good
>> decision for this very little matter.
>>
>> My advice is "keep it simple".
>>
>> If this is a blocker, I can sure write such an algorithm, when I have some
>> spare time, but I'm not sure that the purpose is worth it.
>
> You're probably right, but TBH I'm pretty unsure about this whole thing.

If the question is "is there a bug", then answer is yes. The progress 
report may disappear if thread 0 happens to stop, even of all other 
threads go on. Obviously it only concerns slow queries, but there is no 
reason why pgbench should not work with slow queries. I can imagin good 
reason to do that, say to check the impact of such queries on an OLTP 
load.

The bug can be kept instead, and it can be called a feature.

> I will leave it alone for the time being.

Maybe you could consider pushing the first part of the patch, which stops 
if a transaction is scheduled after the end of the run? Or is this part 
bothering you as well?

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pgbench stats per script & other stuff
Next
From: Alvaro Herrera
Date:
Subject: Re: pgbench small bug fix