Re: BUG #7504: corrupted statistics file "pg_stat_tmp/pgstat.stat"

From: 沈前卫 <shenqw(at)163(dot)net>
To: Euler Taveira <euler(at)timbira(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7504: corrupted statistics file "pg_stat_tmp/pgstat.stat"
Date: 2012-08-27 06:16:01
Message-ID: 503B10A1.8050605@163.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

My English is very poor, below Google Translate:

"It is possible but ... Did you see any ERROR message (s) related to
statistics
collector before those ones? "
-------
Found no other error messages related to this. Disk hardware is also normal.

According to my observation, is the process of "autovacuum launcher
process" will prompt the above error, if error, suggesting that the
number of errors is relatively fixed, 182, such as 2-182, the next
prompt serial number becomes 183-363, and then the next time on 364-544.

I Postgresql code are not familiar with, and probably looked, the "stats
collector process" process to create a "pgstat.tmp" write data, and then
rename the "pgstat.stat" atomic operations, but if "autovacuum launcher
process" is being read "pgstat.stat", "stats collector process" at a
time when the rename operation if integrated autovacuum launcher process
"read the remaining old files or new data file? Is not a problem. If it
is to solve this problem need to process synchronization mechanism to
solve. Only do not have any process to read the file being read
"pgstat.stat", this time to rename operation. This is also the
possibility of error, but the probability is very small. If you want to
completely eliminate this error, you need better synchronization mechanism.

于 2012-8-24 22:22, Euler Taveira 写道:
> On 24-08-2012 00:16, shenqw(at)163(dot)net wrote:
>> Maybe this is a bug.
>> if stats collector process don't product pg_stat_tmp/pgstat.stat file, the
>> autovacuum launcher process will output those WARNING message?
>>
> It is possible but... Did you see any ERROR message(s) related to statistics
> collector before those ones? To solver your problem, you can remove the
> pgstat.stat file that it will be created again next time server starts. Of
> course, you will loose the statistics, hence remember to VACUUM ANALYZE your
> cluster.
>
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2012-08-27 13:58:52 Re: [ADMIN] Repeatable crash in pg_dump (with -d2 info)
Previous Message Bruce Momjian 2012-08-27 03:27:41 Re: [PATCH] Prevent hanging on unreachable hosts on startup