Fabien COELHO wrote: > > >>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.
No, I agree that this looks like a bug and that we should fix it; for example, if all connections from thread 0 terminate for some reason, there will be no more reports, even if the other threads continue. That's bad too. What I'm unsure about is the proposed fix. > >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? So there are *two* bugs here? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
