Re: [HACKERS] 7.0.2 - 7.0.3 problem
"Mitch Vincent" [EMAIL PROTECTED] writes:
DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
Startup failed - abort
The only compilation change I made was to increase BLCKSZ to 32k (which has
been running in a production 7.0.2 environment for quite some time).
This case should now deliver a more reasonable error message in current
sources, ie, something about BLCKSZ mismatch...
regards, tom lane
[HACKERS] 7.0.2 - 7.0.3 problem
I just upgraded to 7.0.3 and tried to start the backend like
/usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
/usr/local/pgsql/data -i /usr/local/pgsql/postgres.log 21
.. as I've done with 7.0.2, it failed to start and got this in my
postgresql.log :
DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
Startup failed - abort
The only compilation change I made was to increase BLCKSZ to 32k (which has
been running in a production 7.0.2 environment for quite some time).
So what's up? Just to make sure I made the permissions 777 all the way down
to pg_control but it had no effect.
Hmm, I just re-installed 7.0.2 and I get the same error with it -- not good.
My development server, which is virtually the same, did fine when I
installed 7.0.3 so I'm guessing it's not a problem across the board..
I also notice in the log that it's Read("/usr/local/pgsql/data/pg_control")
that's failing and when I move pg_control out of the way, it's Open() that
fails..
I did nothing but stop the postmaster, compile and install 7.0.3 and start
the postmaster. then compiled and installed 7.0.2 again and all of the
sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
As always, any help is appreciated. Thanks!
-Mitch
Re: [HACKERS] 7.0.2 - 7.0.3 problem
By the way, what is pg_control and what does it do?
-Mitch
- Original Message -
From: "Michael Ansley" [EMAIL PROTECTED]
To: "'Mitch Vincent '" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, November 12, 2000 4:02 PM
Subject: RE: [HACKERS] 7.0.2 - 7.0.3 problem
You have to dump/initdb/reload if you change the block size. Simply
recompiling is not going to work.
Cheers...
MikeA
-Original Message-
From: Mitch Vincent
To: [EMAIL PROTECTED]
Sent: 11-13-00 12:57 AM
Subject: [HACKERS] 7.0.2 - 7.0.3 problem
I just upgraded to 7.0.3 and tried to start the backend like
/usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
/usr/local/pgsql/data -i /usr/local/pgsql/postgres.log 21
.. as I've done with 7.0.2, it failed to start and got this in my
postgresql.log :
DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
Startup failed - abort
The only compilation change I made was to increase BLCKSZ to 32k (which
has
been running in a production 7.0.2 environment for quite some time).
So what's up? Just to make sure I made the permissions 777 all the way
down
to pg_control but it had no effect.
Hmm, I just re-installed 7.0.2 and I get the same error with it -- not
good.
My development server, which is virtually the same, did fine when I
installed 7.0.3 so I'm guessing it's not a problem across the board..
I also notice in the log that it's
Read("/usr/local/pgsql/data/pg_control")
that's failing and when I move pg_control out of the way, it's Open()
that
fails..
I did nothing but stop the postmaster, compile and install 7.0.3 and
start
the postmaster. then compiled and installed 7.0.2 again and all of the
sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
As always, any help is appreciated. Thanks!
-Mitch
Re: [HACKERS] 7.0.2 - 7.0.3 problem - anyone? - Fixed!
I said: if (ControlFile-blcksz != BLCKSZ) elog(STOP, "database was initialized with BLCKSZ %d,\n\tbut the backend was compiled with BLCKSZ %d.\n\tlooks like you need to initdb.", ControlFile- blcksz, BLCKSZ); But I haven't stress-tested it. From your report, it sounds like something may blow up before control gets to this point if the compiled BLCKSZ is larger than the value used by initdb :-( Oh ... duh! Three statements before the above test, we read in the pg_control data with if (read(fd, ControlFile, BLCKSZ) != BLCKSZ) elog(STOP, "Read(\"%s\") failed: %d", ControlFilePath, errno); Now pg_control is only a one-block file anyway. So if it was written with a smaller BLCKSZ than the backend is expecting, the read() will indeed not read as many bytes as the code is expecting --- whereupon it fails with this not-so-informative error message instead of the one that would be useful. Easy to fix, now that we've had our noses rubbed in the problem. Thanks for the report, and sorry you were confused for awhile... regards, tom lane
Re: [HACKERS] 7.0.2 - 7.0.3 problem - anyone?
Block size can not be changes without dump/reload. If you think it
worked once, you are wrong. Sorry. The page headers have to be written
at the start of every block.
[ Charset ISO-8859-1 unsupported, converting... ]
I realize it's Sunday night and not many people will be checking their
email, however I must ask one final time before I take some drastic measures
(erasing the data directory and initdb 'ing, then restoring the data from
last night's backup, losing an entire day's worth of data) -- does anyone
have any ideas on how I might be able to fix the problems outlined below?
I'm nearly positive that I shouldn't have had to dump/restore or initdb
again, since I made the same changes on another machine with the same
databases, data and BLCKSZ (an upgrade to 7.0.3 without an initdb or
anything), which went flawlessly.
Thanks to anyone who could even offer a guess, I've guessed all I can and
none of my guesses have paid off.. BTW, one might be lead to believe that
this is a permission problem, it's not, I'm positive of that. The same user
was accessing the same file seconds before I upgraded, that and the fact
that I changed permissions to 777 all the way down the tree to make sure..
-Mitch
You have to dump/initdb/reload if you change the block size. Simply
recompiling is not going to work.
Cheers...
MikeA
-Original Message-
From: Mitch Vincent
To: [EMAIL PROTECTED]
Sent: 11-13-00 12:57 AM
Subject: [HACKERS] 7.0.2 - 7.0.3 problem
I just upgraded to 7.0.3 and tried to start the backend like
/usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
/usr/local/pgsql/data -i /usr/local/pgsql/postgres.log 21
.. as I've done with 7.0.2, it failed to start and got this in my
postgresql.log :
DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
Startup failed - abort
The only compilation change I made was to increase BLCKSZ to 32k (which
has
been running in a production 7.0.2 environment for quite some time).
So what's up? Just to make sure I made the permissions 777 all the way
down
to pg_control but it had no effect.
Hmm, I just re-installed 7.0.2 and I get the same error with it -- not
good.
My development server, which is virtually the same, did fine when I
installed 7.0.3 so I'm guessing it's not a problem across the board..
I also notice in the log that it's
Read("/usr/local/pgsql/data/pg_control")
that's failing and when I move pg_control out of the way, it's Open()
that
fails..
I did nothing but stop the postmaster, compile and install 7.0.3 and
start
the postmaster. then compiled and installed 7.0.2 again and all of the
sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
As always, any help is appreciated. Thanks!
-Mitch
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] 7.0.2 - 7.0.3 problem - anyone?
[ Charset ISO-8859-1 unsupported, converting... ] I think I might have explained this wrong.. Ok, both databases had a BLCKSZ of 32k before the upgrade (in 7.0.2), one database that I upgraded first to 7.0.3 went flawlessly, it started, I can do every operation fine and it's BLCKSZ is 32k (so the BLCKSZ never changed between the installs, it is exactly as it was before).. I used the exact same procedure for my production database and it doesn't start.. If I have to dump and reload in this situation, that's fine.. You absolutely know more than I do about PostgreSQL but I know what I did on the development machine and it didn't have these problems -- that's why I didn't think any dump and/or reload was needed... When I went back to 7.0.2, I shouldn't have had to dump and restore, should I? I never did an initdb on the 7.0.3 installation so the data (and virtually everything else as far as data is concerned was the same as when I was running 7.0.2 Knowing all the above, do you still think a dump and reload was required? If so that's fine, I just need to know.. You are correct. It does not need a dump/restore. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] 7.0.2 - 7.0.3 problem - anyone? - Fixed!
It wasn't PostgreSQL, it was me of course! Seeing as it was so long ago, I forgot that the BLCKSZ on the production server wasn't 32k, it was 31k (for whatever reason).. When I set the BLCKSZ lower than that and tried to start the backend it told me that the database was initialized with a BLCKSZ of 31k, strange that it didn't say that when I compiled with a BLCKSZ of 32k but regardless of all that it was my stupidity that was the problem, nothing more.. My apologies for wasting everyone's time, file this problem in the "stupid user" category. Thanks to all, I'm off to sit in the corner for a while... -Mitch - Original Message - From: "Bruce Momjian" [EMAIL PROTECTED] To: "Mitch Vincent" [EMAIL PROTECTED] Sent: Sunday, November 12, 2000 6:47 PM Subject: Re: [HACKERS] 7.0.2 - 7.0.3 problem - anyone? Quite strange. There isn't much in 7.0.3 that would cause that. [ Charset ISO-8859-1 unsupported, converting... ] You are correct. It does not need a dump/restore. Excellent, my apologies for not being clear before... Do you have any other ideas as to what might have caused this problem? -Mitch -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
