On Feb 15, 2007, at 1:46 PM, Alvaro Herrera wrote:
> Casey Duncan wrote:
>> We have a production system with multiple identical database
>> instances on the same hardware, with the same configuration, running
>> databases with the exact same schema. They each have different data,
>> but the database sizes and load patterns are almost exactly the same.
>>
>> We are running pg 8.1.5 (upgraded the day before 8.1.6 came out, oh
>> well ;^) and since then we have noticed the following error on two of
>> the servers:
>>
>> 2007-02-15 00:35:03.324 PST ERROR: could not access status of
>> transaction 2565134864
>> 2007-02-15 00:35:03.325 PST DETAIL: could not open file "pg_clog/
>> 098E": No such file or directory
>
> Can you relate it to autovacuum?
Maybe. Here's what I get when I crank up the logging to debug4:
2007-02-15 14:20:48.771 PST DEBUG: StartTransaction
2007-02-15 14:20:48.771 PST DEBUG: name: unnamed; blockState:
DEFAULT; state: INPROGR, xid/subid/cid: 3429052708/1/0, nestlvl: 1,
children: <>
2007-02-15 14:20:48.771 PST DEBUG: vacuuming "pg_catalog.pg_statistic"
2007-02-15 14:20:48.771 PST ERROR: could not access status of
transaction 2565134864
2007-02-15 14:20:48.772 PST DETAIL: could not open file "pg_clog/
098E": No such file or directory
2007-02-15 14:20:48.772 PST DEBUG: proc_exit(0)
2007-02-15 14:20:48.772 PST DEBUG: shmem_exit(0)
2007-02-15 14:20:48.773 PST DEBUG: exit(0)
2007-02-15 14:20:48.775 PST DEBUG: reaping dead processes
does that imply that it is the pg_statistic table that is hosed?
Interestingly I can manually vacuum that table in all of the
databases on this machine without provoking the error.
-Casey