last_analyze/last_vacuum not being updated

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers