Itagaki Takahiro <[email protected]> writes:
> Some of pg_stat_all_tables.vacuum_count, autovacuum_count, analyze_count
> and autoanalyze_count will be filled with garbages after pg_stat_reset().
> Not all of the tables, but some of tables had corrupted counters.
> It looks we access freed memory. 9187201950435737471 is 7F7F7F7F7F7F7F7F
> filled by CLOBBER_FREED_MEMORY.
> with PG 9.1dev (dfe18f18d262df731378cbf38a4136f08ca119a5) on 64bit Linux
> build with --enable-cassert and --enable-debug.
Hmm ... I see some pretty bogus looking results even without having done
any pg_stat_reset. In the regression database:
regression=# SELECT * FROM pg_stat_all_tables WHERE vacuum_count > 10000;
relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan |
idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup
| n_dead_tup | last_vacuum | last_autovacuum | last_analyze |
last_autoanalyze | vacuum_count | autovacuum_count |
analyze_count | autoanalyze_count
-------+------------+---------------+----------+--------------+----------+---------------+-----------+-----------+-----------+---------------+------------+------------+-------------------------------+-----------------+--------------+---
----------------------------+---------------------+--------------------+----------------+-------------------
28886 | public | rtest_t6 | 5 | 3 | |
| 2 | 0 | 1 | 0 | 1 |
1 | | | |
| 51389285531657 | 0 |
744 | 449
16959 | public | hash_f8_heap | 5 | 50000 | 5 |
4 | 10000 | 2 | 0 | 0 | 10000 |
2 | 2011-03-06 21:00:40.360407-05 | | | 20
11-03-06 21:01:13.400686-05 | 648518346341351425 | 0 |
0 | 1
16872 | public | stud_emp | 15 | 45 | |
| 6 | 0 | 3 | 0 | 3 |
3 | 2011-03-06 21:00:39.925669-05 | | |
| 6052837939400933377 | 144115188075855872 |
0 | 0
16953 | public | hash_txt_heap | 2 | 20000 | 5 |
4 | 10000 | 2 | 0 | 0 | 10000 |
2 | 2011-03-06 21:00:40.322777-05 | | | 20
11-03-06 21:01:10.255983-05 | 16044073672507393 | 0 |
0 | 1
16860 | public | emp | 11 | 33 | |
| 3 | 0 | 0 | 0 | 3 |
0 | 2011-03-06 21:00:39.872212-05 | | |
| 2199023255553 | 0 |
0 | 0
27091 | public | check2_tbl | 1 | 2 | |
| 2 | 0 | 0 | 0 | 2 |
0 | 2011-03-06 21:00:40.676605-05 | | |
| 17592186044417 | 0 |
17592186044416 | 17592186044416
(6 rows)
Even more interesting, although template1 looks OK, right after
switching into a freshly created database I see:
z1=# SELECT * FROM pg_stat_all_tables WHERE vacuum_count > 10000;
relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan |
idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup
| n_dead_tup | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze
|
vacuum_count | autovacuum_count | analyze_count |
autoanalyze_count
-------+------------+---------------+----------+--------------+----------+---------------+-----------+-----------+-----------+---------------+------------+------------+-------------+-----------------+--------------+------------------+--
-------------------+---------------------+---------------------+---------------------
2601 | pg_catalog | pg_am | 2 | 2 | 0 |
0 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
1255 | pg_catalog | pg_proc | 0 | 0 | 23 |
23 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
2617 | pg_catalog | pg_operator | 0 | 0 | 6 |
6 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
1249 | pg_catalog | pg_attribute | 0 | 0 | 55 |
84 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
2619 | pg_catalog | pg_statistic | 0 | 0 | 8 |
6 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
1247 | pg_catalog | pg_type | 0 | 0 | 13 |
13 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
2618 | pg_catalog | pg_rewrite | 0 | 0 | 1 |
1 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
2602 | pg_catalog | pg_amop | 0 | 0 | 8 |
10 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
2616 | pg_catalog | pg_opclass | 0 | 0 | 3 |
3 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
2603 | pg_catalog | pg_amproc | 0 | 0 | 5 |
5 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
2600 | pg_catalog | pg_aggregate | 0 | 0 | 1 |
1 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
2610 | pg_catalog | pg_index | 1 | 109 | 7 |
10 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
1259 | pg_catalog | pg_class | 5 | 916 | 13 |
13 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
2838 | pg_toast | pg_toast_2618 | 0 | 0 | 1 |
3 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
2615 | pg_catalog | pg_namespace | 1 | 6 | 2 |
1 | 0 | 0 | 0 | 0 | 0 |
0 | | | | | 9
187201950435737471 | 9187201950435737471 | 9187201950435737471 |
9187201950435737471
(15 rows)
So yeah, something is pretty hosed here, but I don't think it's
pg_stat_reset's fault ...
regards, tom lane
--
Sent via pgsql-bugs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
