Re: BUG #5327: postgresql gives checksum error when upgrading 8.2.6 binaries to 8.2.14 in windows.

From: janandith jayawardena <janandith(at)gmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5327: postgresql gives checksum error when upgrading 8.2.6 binaries to 8.2.14 in windows.
Date: 2010-02-17 19:21:04
Message-ID: 225bedee1002171121u8d9f498g43f7c71a60ce408f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I've got it working after building with Visual Studio. Thanks. But there is
still a problem when building some .dll files.

The version I'm using is 2008.

When building libecpg there are errors like,

Error 1 error LNK2019: unresolved external symbol _PGTYPESdate_from_asc
referenced in function _ECPGget_data data.obj libecpg

I see PGTYPESdate_from_asc in src/interface/ecpg/pgtypeslib/timestamp.c

why isn't this picked up although I add it to source file list.

There are simillar errors in,

conversion procs collection of projects.

Can you please help me figure this out.

On Tue, Feb 16, 2010 at 10:29 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

>
> The short answer is that you should not be changing any build
> configurations if changing from one minor release to another. Are you
> sure you are using the same build setup?
>
> ---------------------------------------------------------------------------
>
> janandith wrote:
> >
> > The following bug has been logged online:
> >
> > Bug reference: 5327
> > Logged by: janandith
> > Email address: janandith(at)gmail(dot)com
> > PostgreSQL version: 8.2.14
> > Operating system: windows 2003
> > Description: postgresql gives checksum error when upgrading 8.2.6
> > binaries to 8.2.14 in windows.
> > Details:
> >
> > After upgrading postgresql binaries from 8.2.6 to 8.2.14 in windows 2003
> I
> > cannot start the database using postgresql.exe because there is a
> checksum
> > error.
> >
> > What I'm doing is building postgresql 8.2.14 from source code and
> replacing
> > the binaries.
> >
> > In windows I'm building using MSYS and replacing existing .exe files.
> >
> > After the replacement Linux binaries are working without errors. But the
> > windows binaries reads the Date/time type storage: and Locale wrong. It
> > should be be floating-point and C locale but read as 64-bit integers and
> > Locale as @.
> >
> >
> > Following are the results of pg_controldata.
> >
> >
> > Linux
> >
> > pg_control version number: 822
> > Catalog version number: 200611241
> > Database system identifier: 5219167662867643742
> > Database cluster state: in production
> > pg_control last modified: Fri 12 Feb 2010 03:47:00 PM IST
> > Current log file ID: 0
> > Next log file segment: 63
> > Latest checkpoint location: 0/3EA20688
> > Prior checkpoint location: 0/3E9F1084
> > Latest checkpoint's REDO location: 0/3EA20688
> > Latest checkpoint's UNDO location: 0/0
> > Latest checkpoint's TimeLineID: 1
> > Latest checkpoint's NextXID: 0/547350
> > Latest checkpoint's NextOID: 26232
> > Latest checkpoint's NextMultiXactId: 1
> > Latest checkpoint's NextMultiOffset: 0
> > Time of latest checkpoint: Fri 12 Feb 2010 03:47:00 PM IST
> > Minimum recovery ending location: 0/0
> > Maximum data alignment: 4
> > Database block size: 8192
> > Blocks per segment of large relation: 131072
> > WAL block size: 8192
> > Bytes per WAL segment: 16777216
> > Maximum length of identifiers: 64
> > Maximum columns in an index: 32
> > Date/time type storage: floating-point numbers
> > Maximum length of locale name: 128
> > LC_COLLATE: C
> > LC_CTYPE: C
> >
> >
> > Windows
> >
> > WARNING: Calculated CRC checksum does not match value stored in file.
> > Either the file is corrupt, or it has a different layout than this
> program
> > is expecting. The results below are untrustworthy.
> >
> > pg_control version number: 822
> > Catalog version number: 200611241
> > Database system identifier: 5247545044375645930
> > Database cluster state: shut down
> > pg_control last modified: 01.01.1970 01:00:00
> > Current log file ID: 1265884073
> > Next log file segment: 0
> > Latest checkpoint location: 0/30
> > Prior checkpoint location: 0/2F7CA1A8
> > Latest checkpoint's REDO location: 0/2F6F4E60
> > Latest checkpoint's UNDO location: 0/2F7CA1A8
> > Latest checkpoint's TimeLineID: 0
> > Latest checkpoint's NextXID: 0/1
> > Latest checkpoint's NextOID: 0
> > Latest checkpoint's NextMultiXactId: 173924
> > Latest checkpoint's NextMultiOffset: 17725
> > Time of latest checkpoint: 01.01.1970 01:00:01
> > Minimum recovery ending location: 0/4B73DBA9
> > Maximum data alignment: 0
> > Database block size: 8
> > Blocks per segment of large relation: 0
> > WAL block size: 0
> > Bytes per WAL segment: 1093850759
> > Maximum length of identifiers: 8192
> > Maximum columns in an index: 131072
> > Date/time type storage: 64-bit integers
> > Maximum length of locale name: 16777216
> > LC_COLLATE: @
> > LC_CTYPE:
> >
> > --
> > Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-bugs
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message pekka.jarvinen 2010-02-18 09:20:46 BUG #5333: psql returns 0 on error
Previous Message Ben Chobot 2010-02-17 18:06:55 planner regression in 8.4 (from 8.1)