Re: pgbench small bug fix
От | Fabien COELHO |
---|---|
Тема | Re: pgbench small bug fix |
Дата | |
Msg-id | alpine.DEB.2.10.1603041935280.11128@sto обсуждение исходный текст |
Ответ на | Re: pgbench small bug fix (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: pgbench small bug fix
|
Список | 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 по дате отправления: