dbTalk Databases Forums  

[BUGS] BUG #2263: corrupted pgstat.stat file

mailing.database.pgsql-bugs mailing.database.pgsql-bugs


Discuss [BUGS] BUG #2263: corrupted pgstat.stat file in the mailing.database.pgsql-bugs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
 
Posts: n/a

Default [BUGS] BUG #2263: corrupted pgstat.stat file - 02-15-2006 , 10:51 AM







The following bug has been logged online:

Bug reference: 2263
Logged by:
Email address: bug1 (AT) route66 (DOT) ro
PostgreSQL version: 8.1.3
Operating system: Linux x86
Description: corrupted pgstat.stat file
Details:

Hello!

I upgraded from 8.1.2 to 8.1.3 without dumping (was not required). After
starting I got this error in the logs:

LOG: corrupted pgstat.stat file

What should I do?

Thanks!

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply With Quote
  #2  
Old   
Tom Lane
 
Posts: n/a

Default Re: [BUGS] BUG #2263: corrupted pgstat.stat file - 02-15-2006 , 11:40 AM






"" <bug1 (AT) route66 (DOT) ro> writes:
Quote:
I upgraded from 8.1.2 to 8.1.3 without dumping (was not required). After
starting I got this error in the logs:

LOG: corrupted pgstat.stat file

What should I do?
Ignore it. We changed the format of the pgstat file between 8.1.2 and
8.1.3.

2006-01-18 15:35 tgl

* src/: backend/commands/vacuum.c, backend/postmaster/autovacuum.c,
backend/postmaster/pgstat.c, backend/storage/smgr/smgr.c,
include/pgstat.h (REL8_1_STABLE): Modify pgstats code to reduce
performance penalties from oversized stats data files: avoid
creating stats hashtable entries for tables that aren't being
touched except by vacuum/analyze, ensure that entries for dropped
tables are removed promptly, and tweak the data layout to avoid
storing useless struct padding. Also improve the performance of
pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it
exactly once per autovac cycle rather than multiple times or not at
all. This should cure recent complaints about 8.1 showing much
higher stats I/O volume than was seen in 8.0. It'd still be a good
idea to revisit the design with an eye to not re-writing the entire
stats dataset every half second ... but that would be too much to
backpatch, I fear.


regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.