Thread: last_analyze/last_vacuum not being updated
I'm looking at a case on 9.4.1 where the last_analyze and last_vacuum stats for a handful of tables seem stuck. They don't update after running an ANALYZE or VACUUM command, and they don't react to pg_stat_reset_single_table_counters(). All of the affected tables are system catalogs, some shared, some not. Other system catalogs and other tables have their statistics updated normally. Any ideas (before I try to blow it away)?
Peter Eisentraut wrote: > I'm looking at a case on 9.4.1 where the last_analyze and last_vacuum > stats for a handful of tables seem stuck. They don't update after > running an ANALYZE or VACUUM command, and they don't react to > pg_stat_reset_single_table_counters(). All of the affected tables are > system catalogs, some shared, some not. Other system catalogs and other > tables have their statistics updated normally. Any ideas (before I try > to blow it away)? Interesting. Not sure what would cause this. Maybe their pgstat_info pointer is invalid in their relcache entry for some reason. Are these rd_isnailed? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter_e@gmx.net> writes:
> I'm looking at a case on 9.4.1 where the last_analyze and last_vacuum
> stats for a handful of tables seem stuck. They don't update after
> running an ANALYZE or VACUUM command, and they don't react to
> pg_stat_reset_single_table_counters(). All of the affected tables are
> system catalogs, some shared, some not. Other system catalogs and other
> tables have their statistics updated normally. Any ideas (before I try
> to blow it away)?
Hmm ... corrupted hash table inside the stats collector, perhaps?
It would be interesting to look at the stats disk file and see if
there are multiple entries for those OIDs, or if VACUUMing one of
them causes some *other* table's last_vacuum to advance.
regards, tom lane
On 6/8/15 3:16 PM, Peter Eisentraut wrote: > I'm looking at a case on 9.4.1 where the last_analyze and last_vacuum > stats for a handful of tables seem stuck. They don't update after > running an ANALYZE or VACUUM command, and they don't react to > pg_stat_reset_single_table_counters(). All of the affected tables are > system catalogs, some shared, some not. Other system catalogs and other > tables have their statistics updated normally. Any ideas (before I try > to blow it away)? This issue somehow went away before I had time to analyze it further, which is weird in itself. But now I have seen a segfault on a completely different 9.4 instance while querying pg_stat_databases. Could be bad luck. But if others are seeing weird stats collector behavior in 9.4, please share.
On 6/15/15 4:45 PM, Peter Eisentraut wrote: > On 6/8/15 3:16 PM, Peter Eisentraut wrote: >> I'm looking at a case on 9.4.1 where the last_analyze and last_vacuum >> stats for a handful of tables seem stuck. They don't update after >> running an ANALYZE or VACUUM command, and they don't react to >> pg_stat_reset_single_table_counters(). All of the affected tables are >> system catalogs, some shared, some not. Other system catalogs and other >> tables have their statistics updated normally. Any ideas (before I try >> to blow it away)? > > This issue somehow went away before I had time to analyze it further, > which is weird in itself. But now I have seen a segfault on a > completely different 9.4 instance while querying pg_stat_databases. This was probably bug #12918.