|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Alex Shulgin <ash(at)commandprompt(dot)com>|
|Cc:||Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: REVIEW: Track TRUNCATE via pgstat|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Alex Shulgin wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
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
|Next Message||Andres Freund||2014-12-16 14:30:05||Re: WALWriter active during recovery|
|Previous Message||Heikki Linnakangas||2014-12-16 14:25:31||Re: Logical Decoding follows timelines|