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
