Thread: Different BLKSZ
While doing some tests, I have encountered too many problems with incompatible BLKSZ (the backend comipled in different BLKSZ with the one in database). I know this is my fault, but it would be nice if there is better way to avoid this kind of disaster. For example: (1) there is a file called PG_BLKSZ under $PGDATA. (2) postmaster checks the contents of the file to see if it was compiled in the same BLKSZ. (3) If not, give some error messages and exit. Comments? --- Tatsuo Ishii
Tatsuo Ishii wrote: > > While doing some tests, I have encountered too many problems with > incompatible BLKSZ (the backend comipled in different BLKSZ with the > one in database). I know this is my fault, but it would be nice if > there is better way to avoid this kind of disaster. For example: > > (1) there is a file called PG_BLKSZ under $PGDATA. > > (2) postmaster checks the contents of the file to see if it was > compiled in the same BLKSZ. > > (3) If not, give some error messages and exit. There is special file pg_control for the WAL purposes - good place for the BLCKSZ... Vadim
>> While doing some tests, I have encountered too many problems with >> incompatible BLKSZ (the backend comipled in different BLKSZ with the >> one in database). I know this is my fault, but it would be nice if >> there is better way to avoid this kind of disaster. For example: >> >> (1) there is a file called PG_BLKSZ under $PGDATA. >> >> (2) postmaster checks the contents of the file to see if it was >> compiled in the same BLKSZ. >> >> (3) If not, give some error messages and exit. > >There is special file pg_control for the WAL purposes - good >place for the BLCKSZ... Nice. Do you have some functions to access the file? Seems it is a binary file. -- Tatsuo Ishii
Tatsuo Ishii wrote: > > > > >There is special file pg_control for the WAL purposes - good > >place for the BLCKSZ... > > Nice. Do you have some functions to access the file? Seems it is a > binary file. access/transam/xlog.c:StartupXLOG() is called on every database startup and read control file - just add BLCKSZ to struct ControlFileData and check it on startup. Don't forget to initialize this value in BootStrapXLOG() (while creating control file). Vadim
>> >There is special file pg_control for the WAL purposes - good >> >place for the BLCKSZ... >> >> Nice. Do you have some functions to access the file? Seems it is a >> binary file. > >access/transam/xlog.c:StartupXLOG() is called on every database >startup and read control file - just add BLCKSZ to >struct ControlFileData and check it on startup. Don't forget >to initialize this value in BootStrapXLOG() (while creating >control file). Thanks. I will work on this issue. -- Tatsuo Ishii
>>access/transam/xlog.c:StartupXLOG() is called on every database >>startup and read control file - just add BLCKSZ to >>struct ControlFileData and check it on startup. Don't forget >>to initialize this value in BootStrapXLOG() (while creating >>control file). > >Thanks. I will work on this issue. I have committed changes to xlog.c. If the blcksz of database does not match the one of the backend, you will get following error message and postmaster won't start. DEBUG: Data Base System is starting up at Tue Oct 12 19:11:03 1999 FATAL 2: database was initialized in BLCKSZ(0), but the backend was compiled in BLCKSZ(8192) This change requires initdb. -- Tatsuo Ishii
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> While doing some tests, I have encountered too many problems with
> incompatible BLKSZ (the backend comipled in different BLKSZ with the
> one in database). I know this is my fault, but it would be nice if
> there is better way to avoid this kind of disaster.
I think this is a fine idea, but BLKSZ is not the only critical
parameter that should be verified at startup. RELSEG_SIZE is
also critical and should be checked the same way. Are there any
other configuration variables that affect database layout? I can't
think of any offhand, but maybe someone else can.
Another thing I would like to see handled in the same way is some sort
of "database layout serial number" that is not the same as the official
version number. During development we frequently make initdb-forcing
changes to the contents of system tables, and sometimes not everyone
gets the word. (I recall Thomas wasted a few hours that way after a
recent change of mine, for example.) We ought to have an internal
version number in some central source file that can be incremented at
any time by anyone who's committing a change that requires initdb.
That would make sure that no one tries to run updated code against an
incompatible database, even if they haven't been paying close attention
to their hackers email. It could save a lot of wasted effort, I think.
regards, tom lane
> Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > While doing some tests, I have encountered too many problems with > > incompatible BLKSZ (the backend comipled in different BLKSZ with the > > one in database). I know this is my fault, but it would be nice if > > there is better way to avoid this kind of disaster. > > I think this is a fine idea, but BLKSZ is not the only critical > parameter that should be verified at startup. RELSEG_SIZE is > also critical and should be checked the same way. Are there any > other configuration variables that affect database layout? I can't > think of any offhand, but maybe someone else can. I have committed changes for RELSEG_SIZE too. initdb required. --- Tatsuo Ishii