Forum OpenACS Q&A: How can I recover a pg_control file?

Collapse
1: How can I recover a pg_control file?
Posted by Jerry Asher on 09/05/01 01:39 AM
Somehow in upgrading from 7.1.2 to 7.1.3 (and with much operator error along the way), my database became corrupted. The database was completely shutdown at the time of upgrading.

I believe it is only the pg_control file that was damaged.

Is there anyway to create a new pg_control file, based on the contents of the database itself? The symptoms are that the

  • data/global/1262 file has a file size of 8192 bytes and a time stamp of last June.
  • data/global/pg_control has a file size of 16384 bytes and a time stamp of today.
When the postmaster starts up, it tells me that:
database was initialized with BLCKSZ 16384, but the backend was compiled with BLCKSZ 8192. looks like you need an initdb.
I would prefer to not waste my db, and I assume initdb will do just that. Can anything be done to recover the pg_control file?
Collapse
2: Response to How can I recover a pg_control file? (response to 1)
Posted by James Thornton on 09/05/01 05:43 AM
Did you compile Postgres 7.1.3 with BLCKSZ 16384?
Collapse
3: Response to How can I recover a pg_control file? (response to 1)
Posted by Jerry Asher on 09/05/01 05:50 AM
I would have sworn that I had compiled both 7.1.2 and 7.1.3 with BLCKSZ 16384.  The 1262 files is evidence that isn't true and that 7.1.2 was running with BLCKSZ 8192, unless that is, something can truncate a file and not change the modification date.

It's kind of ugly that something in the process wasted the pg_control.  My suspicion is that the corruption occurred when I did a "make check".  I wouldn't have thought that a "make check" would be harmful to an existing installation, and there is nothing in the documentation that suggests that it is, but I am pretty sure that "make check" does an initdb, and I'm into thinking it was an erroneous initdb that skewered me.

Collapse
4: Response to How can I recover a pg_control file? (response to 1)
Posted by Dan Wickstrom on 09/05/01 06:11 AM
I don't think initdb is your problem since it won't run if the PGDATA is not empty: 

1090 nsadmin@localhost:~/sourceforge/openfts >initdb
This database system will be initialized with username "nsadmin".
This user will own all the data files and must also own the server process.
 
initdb: The directory /usr/local/pgsql/data exists but is not empty.
If you want to create a new database system, either remove or empty
the directory /usr/local/pgsql/data or run initdb with
an argument other than /usr/local/pgsql/data.
1091 nsadmin@localhost:~/sourceforge/openfts >psql openacs4
Welcome to psql, the PostgreSQL interactive terminal.
 
Type:  copyright for distribution terms
       h for help with SQL commands
       ? for help on internal slash commands
       g or terminate with semicolon to execute query
       q to quit
 
openacs4=# select version();
                               version
---------------------------------------------------------------------
 PostgreSQL 7.1.1 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
(1 row)
 
openacs4=#

As you can see, initdb won't do anything unless you have already nuked your PGDATA directory.

Collapse
5: Response to How can I recover a pg_control file? (response to 1)
Posted by Jerry Asher on 09/05/01 06:16 AM
yeah, I know too, that's why I said I was "into thinking that..." as opposed to "I think that".  Anyway I'm at a loss as to what in the chain could have overwritten that pg_control file.
Collapse
6: Response to How can I recover a pg_control file? (response to 1)
Posted by Petru Paler on 09/05/01 11:20 AM

I don't know how to recover pg_control, but I was wondering why you compiled 7.1.2 with BLCKSZ 16384? PG 7.1.x has tuple toaster support so you don't need BLCKSZ hacks any more -- long rows are handled automatically.

Collapse
7: Response to How can I recover a pg_control file? (response to 1)
Posted by Jerry Asher on 09/05/01 09:18 PM
I was wondering why you compiled 7.1.2 with BLCKSZ 16384? PG 7.1.x has tuple toaster support so you don't need BLCKSZ hacks any more
The answer is prosaic for the most part.... When I started developing OpenACS, they only had a beta for 7.1 and Roberto's fine documents indicating it wasn't necessary for 7.1 were not available. I believe the encouragement I received to use the beta 7.1 also told me to use a blocksize of 16K.