Alex Shulgin wrote: > 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...
It is always possible that things work just right because two bugs cancel each other. > I'm not sure this is at all possible, but I know for sure it will make > debugging the possible fails harder. Surely if some other patch introduces a failure, nobody will try to debug it by looking only at the failures of this test. > 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. Honestly I think pg_regress is not the right tool to test stat counter updates. It kind-of works today, but only because we don't stress it too much. If you want to create a new test framework for pgstats, and include some tests for truncate, be my guest. -- Á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
