The VMware Knowledge Base provides support solutions, error messages and troubleshooting guides
vFabric Postgres fails with the error: invalid page header in block (2039918)
- The Postgres database does not start
- The Postgres application may fail when accessing data
- In the Postgres logs, you see errors similar to:
2012-11-14 23:00:43.451 UTC alivevm alive ERROR: invalid page header in block 57300 of relation pg_tblspc/16385/PG_9.0_201106101/16386/16873
2012-11-14 23:00:43.451 UTC alivevm alive STATEMENT: select r.RESOURCE_ID, r.ATTRKEY_ID, r.RKATTRIB_ID from ResourceAttributeKey r where (1=1) order by 1
- The underlying storage has failed unexpectedly.
- The application may have been writing to the database when storage went offline.
- Disk/hardware corruption.
- Another application or process overwrote data on the same disk files.
- Log into the system that hosts the affected database with the Postgres super user or change to the Postgres user. For example:
- Back up the database files using a command similar to:
cp -r /path/data/* /path/databu
- Start the
psqlutility by running a command similar to:
psql -d dbname
- Set the parameter to zero pages automatically:
dbname=# SET zero_damaged_pages = on;
- Force a check on the pages using a command similar to:
dbname=# vacuum full tablename;
tablenamewith the name retrieved from the output or error log. In the example log provided in this article, the table name is
- If the
vacuumcommand fails with an error similar to:
PANIC: checksum mismatch: disk has 0, should be 0x5f86405e filename pg_tblspc/16385/PG_9.0_201106101/16386/16873, BlockNum 57296, block specifier 16385/16386/16873/0/57296
See Resolving checksum mismatch errors on VMware vPostgres Standard Edition 9.0/9.1.x (2030160).
- Repeat the process until the
vacuumcommand succeeds without errors.
- Check the table by running a statement similar to:
dbname=# SELECT count(*) FROM tablename;
This is successful if the statement returns a number of rows without errors.
- This procedure zeroes out pages and there will be loss of data in the affected table/indexes.
- The database should start up after following this procedure, but it may not start if the rows lost are needed for application initialization. It may be necessary to rebuild rows according to the needs of the application.
Request a Product Feature
To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.