[BUGS] OSX problem with make check...
I just updated to OS X 10.3.5 and Xcode 1.5 my configure was ./configure --with-rendezvous make this is the error I get with 'make check'. I don't know if it's my fault but i read all the install docs and didn't see that I need to do anything special for the 'make check'... dyld: /Users/postgres/software/postgresql-8.0.0beta1/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb can't open library: /usr/local/pgsql/lib/libpq.3.dylib (No such file or directory, errno = 2) Ted __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1208: Invalid page header
The following bug has been logged online: Bug reference: 1208 Logged by: Robert E Bruccoleri Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: Linux Advanced Server 2.1 and SGI ProPack 2.4 Description:Invalid page header Details: POSTGRESQL BUG REPORT TEMPLATE Your name : Robert Bruccoleri Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Itanium 2 Operating System (example: Linux 2.4.18) : Linux 2.4.21 (SGI Propack 2.4 patch 10074) PostgreSQL version (example: PostgreSQL-7.4.3): PostgreSQL-7.4.3 Compiler used (example: gcc 2.95.2) : Intel C compiler version 8.0 Please enter a FULL description of your problem: I am getting sporadic invalid page header errors when loading or vacuuming databases in parallel. We are in the process of migrating from an SGI Origin 3000 running PostgreSQL 7.4 to an SGI Altix running PostgreSQL 7.4.3. The Altix system has 64 processors with 256 gigabytes of RAM. PostgreSQL was built using a 32K blocksize, and we start the system with a buffer cache of 13 pages. Fdatasync is used for synchronization. We use an LSI Logic storage system to store the PostgreSQL databases as well as for much of our departments data, and we have about 5 terabytes used actively. The filesystem is XFS as delivered by SGI, which wrote it. I do not believe that we have any problems with unreliable disk storage. First, no other users have complained about problems and we have a lot more in use than what PostgreSQL is using. Second, the storage system is an enterprise class Fibre Channel dual controller RAID system designed for high redundancy and reliability. It has no single points of failure. We've been using it for over a year with no problems. We have about 14 active databases, and I loaded all 14 simultaneously. No errors were noted during the load, but upon vacuuming all the databases, one of the databases encountered the following message: INFO: vacuuming "public.relationships" vacuumdb: vacuuming of database "human_genome_042003" failed: ERROR: invalid page header in block 4763 of relation "relationships" There may be others with problems, but vacuumdb quit after this error. I downloaded pg_filedump and I ran it on the file containing this relation specifying a range covering a block around the erroneous block. The two blocks around the bad block have data as I would have expected for the "relationships" table, but the bad block has data from a table in another database. Here is part of the pg_filedump output: *** * PostgreSQL File/Block Formatted Dump Utility - Version 3.0 * * File: 367457 * Options used: -f -R 4763 4763 * * Dump created on: Wed Aug 4 19:47:46 2004 *** Block 4763 - Block Offset: 0x094d8000 Offsets: Lower 0 (0x) Block: Size0 Version0Upper61440 (0xf000) LSN: logid 118874 recoff 0x000d Special 25476 (0x6384) Items:0 Free Space: 61440 Length (including item array): 24 Error: Invalid header information. : 5ad00100 0d00 2200 00f0 Z..."... 0010: 8463 .c.. -- Empty block - no items listed - Error: Invalid special section encountered. 6384: 32343433 3832 a927 ab27 244382...'...'.. 6394: 0100 1edbab73 ...s 63a4: 0e8f3ba6 2200 40e3ffef 2200 ..;."[EMAIL PROTECTED]"... 63b4: 68e2ffef 020a b40a fdb70500 h... 63c4: bbc30500 08008f6e ae001200 02081800 ...n 63d4: 0e00 52313031 5f343438 3834 R101_44884.. 63e4: 1500 1500 4e545f30 31303839 NT_01089 63f4: 335f6735 352e7365 6300 9100 3_g55.sec... 6404: 0f00 70646231 63686b2e 412e2d00 pdb1chk.A.-. 6414: ee00 48e17a14 ae470340 H.z..G.@ 6424: 295c8fc2 f5280640 c3f5285c 8fc20b40 )\...([EMAIL PROTECTED](\...@ 6434: 3d0ad7a3 703d1340 0d00 7f00 [EMAIL PROTECTED] 6444: 06819543 8b6c0640 d7a3703d 0a571040 [EMAIL PROTECTED]@ 6454: 91b8c7d2 87e62640 0078ca40 ..&@.x.@ 6464: 002062c0 . b. 6474: e5fd877a 720918a8 2200 ...zr..."... 6484: a06300f0 2200 a06300f0 020a .c.."c.. 6494: b400800a fdb70500 bbc30500 0800906e ...n 64a4: 01001200
Re: [BUGS] Bug: century/millenium still broken
Dear Tom,
> After all that about numbering centuries and millenia correctly,
> why does CVS tip still give me
>
> regression=# select extract(century from now());
> date_part
> ---
> 20
> (1 row)
> [ ... looks in code ... ]
>
> Apparently it's because you fixed only timestamp_part, and not
> timestamptz_part. I'm not too sure about what timestamp_trunc or
> timestamptz_trunc should do, but they may be wrong as well.
Sigh... as usual, what is not tested does not work:-(
> Could we have a more complete patch?
Please find a submission attached. I hope it really fixes all decade,
century and millenium issues for extract and *_trunc functions on interval
and other timestamp types. If someone could check that the results
are reasonnable, it would be great.
I indeed overlooked the fact that there were two functions. The patch
fixes the code so that both variants agree.
I added comments to interval extractions, because it relies on the C
division to have a negative remainder: -7/10 = 0 and remains -7.
As for *_trunc functions, I have chosen to put the first year of the
century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't
think it would make sense to put 2000 (last year of the 2nd millennium)
for rounding all years of the third millenium.
I also fixed the code so that all decades last 10 years and decade 199
means the 1990's.
I have added some tests that are relevant to deal with tricky cases. The
formula may be simplified, but all these cases must pass. Please keep
them.
Have a nice day,
--
Fabien Coelho - [EMAIL PROTECTED]*** ./src/backend/utils/adt/timestamp.c.origFri Jun 4 15:50:58 2004
--- ./src/backend/utils/adt/timestamp.c Tue Aug 10 16:31:41 2004
***
*** 2727,2737
fsec = 0;
break;
case DTK_MILLENNIUM:
! tm->tm_year = (tm->tm_year / 1000) * 1000;
case DTK_CENTURY:
! tm->tm_year = (tm->tm_year / 100) * 100;
case DTK_DECADE:
! tm->tm_year = (tm->tm_year / 10) * 10;
case DTK_YEAR:
tm->tm_mon = 1;
case DTK_QUARTER:
--- 2727,2752
fsec = 0;
break;
case DTK_MILLENNIUM:
! /* see comments in timestamptz_trunc */
! if (tm->tm_year > 0)
! tm->tm_year = ((tm->tm_year+999) / 1000) *
1000 - 999;
! else
! tm->tm_year = - ((999 - (tm->tm_year-1))/1000)
* 1000 + 1;
case DTK_CENTURY:
! /* see comments in timestamptz_trunc */
! if (tm->tm_year > 0)
! tm->tm_year = ((tm->tm_year+99) / 100) * 100 -
99;
! else
! tm->tm_year = - ((99 - (tm->tm_year-1))/100) *
100 + 1;
case DTK_DECADE:
! /* see comments in timestamptz_trunc */
! if (val != DTK_MILLENNIUM && val != DTK_CENTURY)
! {
! if (tm->tm_year > 0)
! tm->tm_year = (tm->tm_year / 10) * 10;
! else
! tm->tm_year = - ((8-(tm->tm_year-1)) /
10) * 10;
! }
case DTK_YEAR:
tm->tm_mon = 1;
case DTK_QUARTER:
***
*** 2830,2841
tm->tm_sec = 0;
fsec = 0;
break;
case DTK_MILLENNIUM:
! tm->tm_year = (tm->tm_year / 1000) * 1000;
case DTK_CENTURY:
! tm->tm_year = (tm->tm_year / 100) * 100;
case DTK_DECADE:
! tm->tm_year = (tm->tm_year / 10) * 10;
case DTK_YEAR:
tm->tm_mon = 1;
case DTK_QUARTER:
--- 2845,2877
tm->tm_sec = 0;
fsec = 0;
break;
+ /* one may consider DTK_THOUSAND and DTK_HUNDRED... */
case DTK_MILLENNIUM:
! /* truncating to the millennium? what is this supposed
to mean?
!* let us put the first year of the millennium...
!
[BUGS] BUG #1209: Problem related to installation
The following bug has been logged online: Bug reference: 1209 Logged by: Sube Singh Email address: [EMAIL PROTECTED] PostgreSQL version: 7.5 Dev Operating system: WindowsXP Description:Problem related to installation Details: Hi I am facing the problem related to installation of postgresql on windowsXP . Guide me How I configure and start to use it . thanks sube singh ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] 8.0.0beta1: -lpthread missing
System Configuration - Architecture (example: Intel Pentium) : Intel Pentium Operating System (example: Linux 2.4.18) : Linux 2.4.21-grsec (Debian) PostgreSQL version (example: PostgreSQL-8.0): PostgreSQL-8.0.0-beta1 Compiler used (example: gcc 2.95.2) : 2.95.4 Please enter a FULL description of your problem: When configuring --enable-thread-safety the binaries cannot be linked: gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations initdb.o dirmod.o exe c.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -Wl,-rpath,/opt/postgresql-800beta1/li b -lpgport -lz -lreadline -lcrypt -lresolv -lnsl -ldl -lm -o initdb ../../../src/interfaces/libpq/libpq.so: undefined reference to `pthread_getspecific' ../../../src/interfaces/libpq/libpq.so: undefined reference to `pthread_once' ../../../src/interfaces/libpq/libpq.so: undefined reference to `pthread_key_create' ../../../src/interfaces/libpq/libpq.so: undefined reference to `pthread_setspecific' collect2: ld returned 1 exit status Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- # ./configure --prefix=/opt/postgresql-800beta1 --enable-thread-safety # make If you know how this problem might be fixed, list the solution below: - The binaries must be linked with pthread (-lpthread). Regards, Martin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] 8.0.0beta1: make check fails on solaris8
System Configuration - Architecture (example: Intel Pentium) : sun4u sparc SUNW,Ultra-250 Operating System (example: Linux 2.4.18) : Solaris8 (SunOS myhost 5.8 Generic_108528-29 ) PostgreSQL version (example: PostgreSQL-8.0): PostgreSQL-8.0.0 (beta1) Compiler used (example: gcc 2.95.2) : 3.2.3 Please enter a FULL description of your problem: Errors in regression tests (make check) Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- > ./configure --prefix=/opt/postgresql-800beta1 --enable-thread-safety > make > make check make check gives me two errors, see attached diffs file. Martin *** ./expected/float4.out Fri Mar 12 01:25:40 2004 --- ./results/float4.outTue Aug 10 10:07:28 2004 *** *** 51,61 (1 row) SELECT 'infinity'::float4; ! float4 ! -- ! Infinity ! (1 row) ! SELECT ' -INFINiTY '::float4; float4 --- --- 51,57 (1 row) SELECT 'infinity'::float4; ! ERROR: invalid input syntax for type real: "infinity" SELECT ' -INFINiTY '::float4; float4 --- *** *** 70,82 SELECT ' INFINITYx'::float4; ERROR: invalid input syntax for type real: " INFINITYx" SELECT 'Infinity'::float4 + 100.0; ! ERROR: type "double precision" value out of range: overflow SELECT 'Infinity'::float4 / 'Infinity'::float4; ! ?column? ! -- ! NaN ! (1 row) ! SELECT 'nan'::float4 / 'nan'::float4; ?column? -- --- 66,74 SELECT ' INFINITYx'::float4; ERROR: invalid input syntax for type real: " INFINITYx" SELECT 'Infinity'::float4 + 100.0; ! ERROR: invalid input syntax for type real: "Infinity" SELECT 'Infinity'::float4 / 'Infinity'::float4; ! ERROR: invalid input syntax for type real: "Infinity" SELECT 'nan'::float4 / 'nan'::float4; ?column? -- == *** ./expected/float8.out Fri Apr 23 22:32:20 2004 --- ./results/float8.outTue Aug 10 10:07:28 2004 *** *** 51,61 (1 row) SELECT 'infinity'::float8; ! float8 ! -- ! Infinity ! (1 row) ! SELECT ' -INFINiTY '::float8; float8 --- --- 51,57 (1 row) SELECT 'infinity'::float8; ! ERROR: invalid input syntax for type double precision: "infinity" SELECT ' -INFINiTY '::float8; float8 --- *** *** 70,82 SELECT ' INFINITYx'::float8; ERROR: invalid input syntax for type double precision: " INFINITYx" SELECT 'Infinity'::float8 + 100.0; ! ERROR: type "double precision" value out of range: overflow SELECT 'Infinity'::float8 / 'Infinity'::float8; ! ?column? ! -- ! NaN ! (1 row) ! SELECT 'nan'::float8 / 'nan'::float8; ?column? -- --- 66,74 SELECT ' INFINITYx'::float8; ERROR: invalid input syntax for type double precision: " INFINITYx" SELECT 'Infinity'::float8 + 100.0; ! ERROR: invalid input syntax for type double precision: "Infinity" SELECT 'Infinity'::float8 / 'Infinity'::float8; ! ERROR: invalid input syntax for type double precision: "Infinity" SELECT 'nan'::float8 / 'nan'::float8; ?column? -- == ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Windows XP Service Pack 2 install failed
I tried to install on XP SP2 and it failed with this error in the event log. Product: PostgreSQL 8.0-beta1 -- Failed to run initdb: 1! Please see the logfile in 'C:\Program Files\PostgreSQL\8.0-beta1\tmp\initdb.log'. I couldn't find the log file because the installation removed all the files in that directory. Geoff ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] SOLARIS 9 ULTRASPARC BUILD
hello, attached are the regression.out and regression.diffs files from make check on a Ultra 2 dual 300MHz CPU running Solaris 9 OS. Looks like no errorbut the expected due to difference in fp results. regression.diffs Description: Binary data regression.out Description: Binary data ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Locale bug?
Hi, if I choose in new version 8.0 for win32 czech locales then lc-collate is czech_czech republic.1250. So I suppose that strings are compared by WIN1250 charset, but database encoding can't be set as WIN1250 (only ISO8859-2=LATIN2) and then ORDER BY don't work correctly. I try make initdb myself, but locales cs_CZ.ISO8859-2 is wrong name. Where I find suported locales with corect names? Or where is problem? Thx Vaclav Vozar ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] 8.0: Absolute path required for INITDB?
hi, Josh Berkus wrote, On 8/9/2004 21:20: Tom, Well, that does deserve investigation. But I've been initdb'ing frequently and not noticed any problems. What configure switches did you use exactly? Did you try to move the installation tree after configure? Here's the issue: if you start initdb from a directory other than PGBASE, you can run into trouble: [EMAIL PROTECTED]:/usr/local/pg80b/bin> ./initdb -D ../data initdb: file "/usr/local/pg80b/bin/share/postgresql/postgres.bki" does not exist This means you have a corrupted installation or identified the wrong directory with the invocation option -L. [EMAIL PROTECTED]:/usr/local/pg80b/bin> same problem here, but I did a trick, changed the $libdir in share/conversion_create.sql to full path to lib dir, and I did a symlink in bin to share. C. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] Installation of PostgreSQL
Sir/Madam I want to use PpstgreSQL windows 98 . But I am facing problem related to installation . How I configure it on my system. thanks Regards sube singh Yahoo! India Matrimony: Find your life partner online.
[BUGS] PG 8.0.0 on OpenBSD problems
7.* compiles clean and runs happy under the same shell / settings / etc bpalmer:/usr/home/bpalmer/CODE/postgresql-8.0.0beta1$ uname -an OpenBSD psidion.crimelabs.net 3.5 GENERIC#34 i386 gmake[4]: Leaving directory `/usr/home/bpalmer/CODE/postgresql-8.0.0beta1/src/port' gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -DFRONTEND -I../../../src/interfaces/libpq -I../../../src/include -c -o initdb.o initdb.c initdb.c: In function `get_encoding_from_locale': initdb.c:744: `CODESET' undeclared (first use in this function) initdb.c:744: (Each undeclared identifier is reported only once initdb.c:744: for each function it appears in.) gmake[3]: *** [initdb.o] Error 1 gmake[3]: Leaving directory `/usr/home/bpalmer/CODE/postgresql-8.0.0beta1/src/bin/initdb' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/home/bpalmer/CODE/postgresql-8.0.0beta1/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/home/bpalmer/CODE/postgresql-8.0.0beta1/src' gmake: *** [all] Error 2 *** Error code 2 c: 917-697-8665h: 201-435-6226 b. palmer, [EMAIL PROTECTED] pgp:crimelabs.net/bpalmer.pgp5 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] Locale bug?
VÃclav VozÃr wrote: > if I choose in new version 8.0 for win32 czech locales then > lc-collate is czech_czech republic.1250. So I suppose that strings > are compared by WIN1250 charset, but database encoding can't be set > as WIN1250 (only ISO8859-2=LATIN2) and then ORDER BY don't work > correctly. I try make initdb myself, but locales cs_CZ.ISO8859-2 is > wrong name. Where I find suported locales with corect names? Or where > is problem? Did you set your client encoding? If not, you are probably inserting WIN 1250-encoded characters without the system knowing about it. If that happens, the ordering can be incorrect. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] 8.0.0beta1: make check fails on solaris8
=?ISO-8859-15?Q?Martin_M=FCnstermann?= <[EMAIL PROTECTED]> writes: > make check gives me two errors, see attached diffs file. See my response to Andrea just now: This seems quite bizarre: ' -INFINiTY ' works but 'infinity' does not? Please try in psql \set VERBOSITY verbose SELECT 'infinity'::float4; and send along the output. My best guess about it is that strtod() is actively broken on your platform, and is recognizing the "infinity" input but returning an incorrect endptr. I seem to recall that we've heard of such bugs before. Can you check for any updates from Sun that might affect strtod()? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] SOLARIS 9 ULTRASPARC BUILD
[EMAIL PROTECTED] writes: > attached are the regression.out and regression.diffs files from make check on a > Ultra 2 dual 300MHz CPU running Solaris 9 OS. This seems quite bizarre: ' -INFINiTY ' works but 'infinity' does not? Please try in psql \set VERBOSITY verbose SELECT 'infinity'::float4; and send along the output. My best guess about it is that strtod() is actively broken on your platform, and is recognizing the "infinity" input but returning an incorrect endptr. I seem to recall that we've heard of such bugs before. Can you check for any updates from Sun that might affect strtod()? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] 8.0.0beta1: -lpthread missing
On Tuesday 10 August 2004 05:14, Martin Münstermann wrote:
> System Configuration
> -
>Architecture (example: Intel Pentium) : Intel Pentium
>
>Operating System (example: Linux 2.4.18) : Linux 2.4.21-grsec
> (Debian)
>
>PostgreSQL version (example: PostgreSQL-8.0): PostgreSQL-8.0.0-beta1
>
>Compiler used (example: gcc 2.95.2) : 2.95.4
>
>
> Please enter a FULL description of your problem:
>
> When configuring --enable-thread-safety the binaries cannot be linked:
> gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations initdb.o dirmod.o exe
> c.o -L../../../src/interfaces/libpq -lpq -L../../../src/port
> -Wl,-rpath,/opt/postgresql-800beta1/li
> b -lpgport -lz -lreadline -lcrypt -lresolv -lnsl -ldl -lm -o initdb
> ../../../src/interfaces/libpq/libpq.so: undefined reference to
> `pthread_getspecific'
> ../../../src/interfaces/libpq/libpq.so: undefined reference to
> `pthread_once'
> ../../../src/interfaces/libpq/libpq.so: undefined reference to
> `pthread_key_create'
> ../../../src/interfaces/libpq/libpq.so: undefined reference to
> `pthread_setspecific'
> collect2: ld returned 1 exit status
>
>
>
> Please describe a way to repeat the problem. Please try to provide a
> concise reproducible example, if at all possible:
> --
> # ./configure --prefix=/opt/postgresql-800beta1 --enable-thread-safety
> # make
>
>
> If you know how this problem might be fixed, list the solution below:
> -
> The binaries must be linked with pthread (-lpthread).
>
Can you take a look at the thread below and report back if that fixes your
problem? http://archives.postgresql.org/pgsql-hackers/2004-08/msg00525.php
--
Robert Treat
Build A Better Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1209: Problem related to installation
Please search for pginstaller and use that. --- PostgreSQL Bugs List wrote: > > The following bug has been logged online: > > Bug reference: 1209 > Logged by: Sube Singh > > Email address: [EMAIL PROTECTED] > > PostgreSQL version: 7.5 Dev > > Operating system: WindowsXP > > Description:Problem related to installation > > Details: > > > Hi > > I am facing the problem related to installation of postgresql on windowsXP > . Guide me How I configure > and start to use it . > > > thanks > > sube singh > > > ---(end of broadcast)--- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] SOLARIS 9 ULTRASPARC BUILD
On Tue, Aug 10, 2004 at 03:23:33PM -0400, Tom Lane wrote: > [EMAIL PROTECTED] writes: > > attached are the regression.out and regression.diffs files from make check on a > > Ultra 2 dual 300MHz CPU running Solaris 9 OS. > > This seems quite bizarre: ' -INFINiTY ' works but > 'infinity' does not? Please try in psql > > \set VERBOSITY verbose >SELECT 'infinity'::float4; > > and send along the output. > > My best guess about it is that strtod() is actively broken on your > platform, and is recognizing the "infinity" input but returning an > incorrect endptr. I seem to recall that we've heard of such bugs > before. Can you check for any updates from Sun that might affect > strtod()? strtod() on Solaris has long returned the wrong endptr when parsing "infinity". Somebody asked about it in comp.unix.solaris in 1995 and I asked again this morning: http://groups.google.com/groups?&threadm=4118e611%241_3%40omega.dimensional.com The response indicates that it's a bug fixed in Solaris 10 but probably not released as a patch in earlier versions. Here's what I get when I run the above commands using a recently CVS'ed 8.0.0beta1 on Solaris 9. Interestingly, it works the first time but not afterwards, perhaps due to the bogus endptr pointing to memory that's initially zeroed but that gets filled before subsequent queries. test=> \set VERBOSITY verbose test=> SELECT 'infinity'::float4; float4 -- Infinity (1 row) test=> SELECT 'infinity'::float4; ERROR: 22P02: invalid input syntax for type real: "infinity" LOCATION: float4in, float.c:330 -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Installation of PostgreSQL
Sube Singh wrote: Sir/Madam I want to use PpstgreSQL windows 98 . But I am facing problem related to installation . How I configure it on my system. Is better you explain better your problem. Howevere if you are speaking about the 8.0beta1 installation I have to advice you that postgres on Win32 works only if the filesystem is journalized, NTFS for istance. Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] OSX problem with make check...
Adam Witney <[EMAIL PROTECTED]> writes: > Ah, setting DYLD_LIBRARY_PATH does the trick Great. I'll add that to pg_regress.sh. > I notice that it has never built a .dylib library before... In 7.4.x I have > always had a libpq.so library. Is this new? Yup. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] OSX problem with make check...
Theodore Petrosky <[EMAIL PROTECTED]> writes: > this is the error I get with 'make check'. > dyld: > /Users/postgres/software/postgresql-8.0.0beta1/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb > can't open library: /usr/local/pgsql/lib/libpq.3.dylib > (No such file or directory, errno = 2) Depending on how sticky the OS is about shared library paths, you may have to do "make install" (at least for the main libraries such as libpq) before you can "make check". Otherwise the libraries will not be where the executables look for them. pg_regress.sh tries to deal with this by setting LD_LIBRARY_PATH, but evidently that doesn't work on OS X. Do you know any other similar incantation that does work? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] OSX problem with make check...
I hope we are okay with this... I tried your path and it didn't work ... I am in bash so I did: export env DYLD_LIBRARY_PATH=/Users/postgres/software/postgresql-8.0.0beta1/src/interfaces/libpq Let me know if there is something else I could try. Ted --- Tom Lane <[EMAIL PROTECTED]> wrote: > Adam Witney <[EMAIL PROTECTED]> writes: > > Ah, setting DYLD_LIBRARY_PATH does the trick > > Great. I'll add that to pg_regress.sh. > > > I notice that it has never built a .dylib library > before... In 7.4.x I have > > always had a libpq.so library. Is this new? > > Yup. > > regards, tom lane > > ---(end of > broadcast)--- > TIP 3: if posting/reading through Usenet, please > send an appropriate > subscribe-nomail command to > [EMAIL PROTECTED] so that your > message can get through to the mailing list > cleanly > __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] 8.0.0beta1: -lpthread missing
In fact, backup in the output and look at the flags used to build libpq.
Are they correct? If they are, you shouldn't need any additional flags
when building initdb because initdb doesn't call any threaded functions,
_except_ if you have that limitation that a libpq using threads requries
a thread flag for everything that calls libpq.
Please report back.
---
Robert Treat wrote:
> On Tuesday 10 August 2004 05:14, Martin M?nstermann wrote:
> > System Configuration
> > -
> >Architecture (example: Intel Pentium) : Intel Pentium
> >
> >Operating System (example: Linux 2.4.18) : Linux 2.4.21-grsec
> > (Debian)
> >
> >PostgreSQL version (example: PostgreSQL-8.0): PostgreSQL-8.0.0-beta1
> >
> >Compiler used (example: gcc 2.95.2) : 2.95.4
> >
> >
> > Please enter a FULL description of your problem:
> >
> > When configuring --enable-thread-safety the binaries cannot be linked:
> > gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> > -Wmissing-declarations initdb.o dirmod.o exe
> > c.o -L../../../src/interfaces/libpq -lpq -L../../../src/port
> > -Wl,-rpath,/opt/postgresql-800beta1/li
> > b -lpgport -lz -lreadline -lcrypt -lresolv -lnsl -ldl -lm -o initdb
> > ../../../src/interfaces/libpq/libpq.so: undefined reference to
> > `pthread_getspecific'
> > ../../../src/interfaces/libpq/libpq.so: undefined reference to
> > `pthread_once'
> > ../../../src/interfaces/libpq/libpq.so: undefined reference to
> > `pthread_key_create'
> > ../../../src/interfaces/libpq/libpq.so: undefined reference to
> > `pthread_setspecific'
> > collect2: ld returned 1 exit status
> >
> >
> >
> > Please describe a way to repeat the problem. Please try to provide a
> > concise reproducible example, if at all possible:
> > --
> > # ./configure --prefix=/opt/postgresql-800beta1 --enable-thread-safety
> > # make
> >
> >
> > If you know how this problem might be fixed, list the solution below:
> > -
> > The binaries must be linked with pthread (-lpthread).
> >
>
> Can you take a look at the thread below and report back if that fixes your
> problem? http://archives.postgresql.org/pgsql-hackers/2004-08/msg00525.php
>
> --
> Robert Treat
> Build A Better Lamp :: Linux Apache {middleware} PostgreSQL
>
> ---(end of broadcast)---
> TIP 8: explain analyze is your friend
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] 8.0.0beta1: -lpthread missing
Robert Treat wrote: > > `pthread_once' > > ../../../src/interfaces/libpq/libpq.so: undefined reference to > > `pthread_key_create' > > ../../../src/interfaces/libpq/libpq.so: undefined reference to > > `pthread_setspecific' > > collect2: ld returned 1 exit status > > > > > > > > Please describe a way to repeat the problem. Please try to provide a > > concise reproducible example, if at all possible: > > -- > > # ./configure --prefix=/opt/postgresql-800beta1 --enable-thread-safety > > # make > > > > > > If you know how this problem might be fixed, list the solution below: > > - > > The binaries must be linked with pthread (-lpthread). > > > > Can you take a look at the thread below and report back if that fixes your > problem? http://archives.postgresql.org/pgsql-hackers/2004-08/msg00525.php I looked at that. The line that does the tests is in config/acx_pthread.m4: acx_pthread_flags="pthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-conf ig" so you should see that list tried. Does that help? I am majorly concerned that Slackware has the same problem as Unixware, meaning that if you use threading in the lib, you now need the flags on every applicaiton that uses the lib. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
