Thread: Re: 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" <pgman@candle.pha.pa.us>
To: "Mitch Vincent" <mitch@venux.net>
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
>   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
>

"Mitch Vincent" <mitch@venux.net> writes:
> 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..

Hmm, there is a test specifically designed to catch this mistake in
backend/access/transam/xlog.c: the initdb-time BLCKSZ is stored in
pg_control, and we have

    if (ControlFile->blcksz != BLCKSZ)
        elog(STOP, "database was initialized with BLCKSZ %d,\n\tbut the backend was compiled with BLCKSZ %d.\n\tlooks
likeyou 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 :-(

            regards, tom lane

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