Alex Shulgin wrote: > Jim Nasby <jim.na...@bluetreble.com> writes:
> > The test also adds 2.5 seconds of forced pg_sleep. I think that's both > > bad and unnecessary. When I removed the sleeps I still saw times of > > less than 0.1 seconds. > > Well, I never liked that part, but the stats don't get updated if we > don't put the session to sleep for at least PGSTAT_STAT_INTERVAL (which > is 500ms). > > Removing these extra sleep calls would theoretically not make a > difference as wait_for_trunc_test_stats() seems to have enough sleep > calls itself, but due to the pgstat_report_stat() being called from the > main loop only, there's no way short of placing the explicit pg_sleep at > top level, if we want to be able to check the effects reproducibly. > > 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? I agree that tests that sleep are annoying. (Try running the "timeout" isolation test a few times and you'll see what I mean.) -- Á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
