Re: REVIEW: Track TRUNCATE via pgstat

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
Date: 2014-12-16 14:29:37
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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
> 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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
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