Alvaro Herrera <alvhe...@2ndquadrant.com> writes: >> >> Another idea would be exposing pgstat_report_stat(true) at SQL level. >> That would eleminate the need for explicit pg_sleep(>=0.5), but we'll >> still need the wait_for_... call to make sure the collector has picked >> it up. > > We already have a stats test that sleeps. Why not add this stuff there, > to avoid making another test slow?
Well, if we could come up with a set of statements to test that would produce the end result unambigously, so that we can be certain the stats we check at the end cannot be a result of neat interaction of buggy behavior... I'm not sure this is at all possible, but I know for sure it will make debugging the possible fails harder. Even with the current approach of checking the stats after every isolated case it's sometimes takes quite a little more than a glance to verify correctness due to side-effects of rollback (ins/upd/del counters are still updated), and the way stats are affecting the dead tuples counter. I'll try to see if the checks can be converged though. -- Alex -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers