Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id B9F5D64FC26 for ; Thu, 25 Sep 2008 15:49:51 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 79484-06 for ; Thu, 25 Sep 2008 15:49:48 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail137091.authsmtp.co.uk (outmail137091.authsmtp.co.uk [62.13.137.91]) by postgresql.org (Postfix) with ESMTP id EE27664FC01 for ; Thu, 25 Sep 2008 15:49:47 -0300 (ADT) Received: from mail-c187.authsmtp.com (mail-c187.authsmtp.com [62.13.128.33]) by punt4.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m8PInexT067992; Thu, 25 Sep 2008 19:49:40 +0100 (BST) Received: from [192.168.0.3] (85-211-71-126.dyn.gotadsl.co.uk [85.211.71.126]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m8PIncCV005039; Thu, 25 Sep 2008 19:49:38 +0100 (BST) Subject: Re: [ADMIN] Postgres Stats after Crash Recovery From: Simon Riggs To: chirag.dave@gmail.com Cc: pgsql-bugs@postgresql.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 25 Sep 2008 19:50:39 +0100 Message-Id: <1222368639.4445.831.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: b56973b7-8b32-11dd-8155-001185d377ca X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadBtFagBbflxB HGQLW1xEUVR7XWp/ aAMfZQBDYEtPQQJr TklLRE1QEQdtHhxP WxZ+K0chBGNGeHtw Zk8sWnVcXgoocEB0 RU0GEnAON2RidWEe BBRFfwJRdR5Kfh5E YlUrV3QKMjRJBC9q VzwaExUQGwAXECNO Xg4XIElaeloCAiV0 Th4eEC9nNlcMXCV7 FREtLUARBld5 X-Authentic-SMTP: 61633235383639.squirrel.dmpriest.net.uk:1378/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/157 X-Sequence-Number: 21447 I confirm this as a bug. First ANALYZE after crash recovery leaves stats showing as zeroes. Repeatable on CVS HEAD with ANALYZE and VACUUM ANALYZE. Forwarding to bugs. On Wed, 2008-09-24 at 15:29 -0400, Chirag Dave wrote: > > Testing AutoVac on 8.3 , i came across the problem of loosing stats > data, which was discussed in my last post > > http://archives.postgresql.org/pgsql-general/2008-08/msg00198.php > > that problem was recognized that doing hard stop, server will throw > away the stats while going through crash recovery. > > Problem i see is after crash recovery , we have to manually analyze > database in order for autovac to work but it not working as expected. > > Here is test case: > > foo=# SELECT version(); > > version > ------------------------------------------------------------------------------------------------ > PostgreSQL 8.3.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) > 4.1.2 (Ubuntu 4.1.2-0ubuntu4) > (1 row) > > foo=# SELECT * from pg_stat_user_tables where relname='accounts'; > -[ RECORD 1 ]----+------------------------------ > relid | 57350 > schemaname | public > relname | accounts > seq_scan | 1 > seq_tup_read | 1000000 > idx_scan | 0 > idx_tup_fetch | 0 > n_tup_ins | 1000000 > n_tup_upd | 0 > n_tup_del | 0 > n_tup_hot_upd | 0 > n_live_tup | 1000000 > n_dead_tup | 0 > last_vacuum | 2008-09-24 15:04:35.384012-04 > last_autovacuum | > last_analyze | 2008-09-24 15:04:35.384012-04 > last_autoanalyze | > > > Next i will stop DB immediate and expect to loose stats as normal > behavior. > > pg_ctl -m immediate -D /opt/rg/foo/pgsql83 stop > waiting for server to shut down...LOG: received immediate shutdown > request > done > server stopped > > After stating the DB, as expected: > foo=# SELECT * from pg_stat_user_tables where relname='accounts'; > -[ RECORD 1 ]----+--------- > relid | 57350 > schemaname | public > relname | accounts > seq_scan | 0 > seq_tup_read | 0 > idx_scan | 0 > idx_tup_fetch | 0 > n_tup_ins | 0 > n_tup_upd | 0 > n_tup_del | 0 > n_tup_hot_upd | 0 > n_live_tup | 0 > n_dead_tup | 0 > last_vacuum | > last_autovacuum | > last_analyze | > last_autoanalyze | > > Next step is to manually analyse to collects the stats again: > foo=# ANALYZE ; > ANALYZE > foo=# SELECT * from pg_stat_user_tables where relname='accounts'; > -[ RECORD 1 ]----+--------- > relid | 57350 > schemaname | public > relname | accounts > seq_scan | 0 > seq_tup_read | 0 > idx_scan | 0 > idx_tup_fetch | 0 > n_tup_ins | 0 > n_tup_upd | 0 > n_tup_del | 0 > n_tup_hot_upd | 0 > n_live_tup | 0 > n_dead_tup | 0 > last_vacuum | > last_autovacuum | > last_analyze | > last_autoanalyze | > > note: After ANALYSE, ststs were not updated. > > Running ANALYSE, second time seems to does the trick. > > foo=# ANALYZE ; > ANALYZE > foo=# SELECT * from pg_stat_user_tables where relname='accounts'; > -[ RECORD 1 ]----+------------------------------ > relid | 57350 > schemaname | public > relname | accounts > seq_scan | 0 > seq_tup_read | 0 > idx_scan | 0 > idx_tup_fetch | 0 > n_tup_ins | 0 > n_tup_upd | 0 > n_tup_del | 0 > n_tup_hot_upd | 0 > n_live_tup | 1000062 > n_dead_tup | 0 > last_vacuum | > last_autovacuum | > last_analyze | 2008-09-24 15:13:13.423424-04 > last_autoanalyze | > > > So question i have is, is this normal operation,why we need to analyze > twice to updates the stats ? if table/tables are candidate for > vacuuming after crash recovery will never get auto-vac unless you do > 'ANALYZE' twice. > > Thanks in advance, > > Chirag Dave > DBA > Afilias -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support