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: pgsql-hackers@postgresql.org
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 2>&1 &

.. 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


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: pgsql-hackers@postgresql.org
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 2>&1 &

.. 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
Mon, 13 Nov 2000 00:02:00 -0000
Michael Ansley <Michael.Ansley@intec-telecom-systems.com>
RE: 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" <Michael.Ansley@intec-telecom-systems.com>
To: "'Mitch Vincent '" <mitch@venux.net>
Cc: <pgsql-hackers@postgresql.org>
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: pgsql-hackers@postgresql.org
> 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 2>&1 &
> 
> .. 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
> 


Sun, 12 Nov 2000 17:11:26 -0800
"Mitch Vincent" <mitch@venux.net>
Re: 7.0.2 -> 7.0.3 problem
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: pgsql-hackers@postgresql.org
> > 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 2>&1 &
> >
> > .. 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
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 12 Nov 2000 21:34:20 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
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
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 12 Nov 2000 21:44:36 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] 7.0.2 -> 7.0.3 problem - anyone?
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: pgsql-hackers@postgresql.org
> 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 2>&1 &
>
> .. 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
>


Sun, 12 Nov 2000 19:18:31 -0800
"Mitch Vincent" <mitch@venux.net>
Re: 7.0.2 -> 7.0.3 problem - anyone?
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..

-Mitch

----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "Mitch Vincent" <mitch@venux.net>
Cc: <pgsql-hackers@postgresql.org>; <pgsql-general@postgresql.org>
Sent: Sunday, November 12, 2000 6:34 PM
Subject: 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: pgsql-hackers@postgresql.org
> > > 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 2>&1 &
> > >
> > > .. 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
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
>


Sun, 12 Nov 2000 19:48:12 -0800
"Mitch Vincent" <mitch@venux.net>
Re: 7.0.2 -> 7.0.3 problem - anyone?