[BUGS] postgres.h missing
Darren Cook ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description postgres.h missing Long Description include/postgres.h is no longer there. php4 tries to include it, so now fails to compile. postgres_fe.h says: * This should be the first file included by PostgreSQL client libraries and * application programs --- but not by backend modules, which should include * postgres.h. ...which sounds like postgres.h should be there. I created a dummy postgres.h which just includes postgres_fe.h and php4 now compiles. (BTW php4 is patched in CVS to include postgres_fe.h instead of postgres.h). Sample Code No file was uploaded with this report ---(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] postgres.h missing
[EMAIL PROTECTED] writes: > (BTW php4 is patched in CVS to include postgres_fe.h instead of postgres.h). PHP *should* have been patched to not include either one. If they didn't get it right yet, would you rattle their cage a little more? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] 7.1 Build fails with Bash and CDPATH
Mark Hollomon ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description 7.1 Build fails with Bash and CDPATH Long Description If using Bash with CDPATH set, the build of 7.1 fails with the following messages: gmake[2]: Entering directory `/home/mhh/src/postgresql-7.1/src/backend' prereqdir=`cd parser/ && pwd` && \ cd ../../src/include/parser/ && rm -f parse.h && \ ln -s $prereqdir/parse.h . ln: .//parser exists gmake[2]: *** [../../src/include/parser/parse.h] Error 1 gmake[2]: *** Deleting file `../../src/include/parser/parse.h' gmake[2]: Leaving directory `/home/mhh/src/postgresql-7.1/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/mhh/src/postgresql-7.1/src' gmake: *** [all] Error 2 I believe the following patch to backend/Makefile solves the problem: *** Makefile.orig Tue Apr 24 09:27:44 2001 --- MakefileTue Apr 24 09:29:47 2001 *** *** 97,103 # up to date when we update the base file. $(top_builddir)/src/include/parser/parse.h: $(srcdir)/parser/parse.h ! prereqdir=`cd $(dir $<) && pwd` && \ cd $(dir $@) && rm -f $(notdir $@) && \ $(LN_S) $$prereqdir/$(notdir $<) . --- 97,103 # up to date when we update the base file. $(top_builddir)/src/include/parser/parse.h: $(srcdir)/parser/parse.h ! prereqdir=`cd $(dir $<) > /dev/null && pwd` && \ cd $(dir $@) && rm -f $(notdir $@) && \ $(LN_S) $$prereqdir/$(notdir $<) . Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] incompatible return type for netmask(inet) function between 7.0.3 and 7.1
Vadim Passynkov ([EMAIL PROTECTED]) reports a bug with a severity of 4 The lower the number the more severe it is. Short Description incompatible return type for netmask(inet) function between 7.0.3 and 7.1 Long Description Function netmask(inet) change return type from 7.0.3 to 7.1 In 7.0.3 return type was text, in 7.1 return type inet Realy in 7.1 added text(inet) and of course need that host and netmask have return type inet, but host in 7.1 still return text. Other problem this changes that dump code from 7.0.3 incompatible with 7.1. Sample Code Version 7.0.3 template1=# \df netmask List of functions Result | Function | Arguments +--+--- text | netmask | inet (1 row) template1=# \df host List of functions Result | Function | Arguments +--+--- text | host | inet (1 row) Version 7.1 template1=# \df netmask List of functions Result | Function | Arguments +--+--- inet | netmask | inet (1 row) template1=# \df host List of functions Result | Function | Arguments +--+--- text | host | inet (1 row) No file was uploaded with this report ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] pg_regress hangs on parallel test
Mark Hollomon ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description pg_regress hangs on parallel test Long Description HPUX 10.20 postgreSQL 7.1 pg_regress hangs on the second set of parallel tests. It never finishes (waited an hour) and several zombie process are left around. Also, the 'master' process continues rack up CPU time. If pg_regress is run explicitly using Bash e.g /gnu/bin/bash ./pg_regress ... everything works. The serial tests pass fine. output for a run that hangs --- ./pg_regress --temp-install --top-builddir=../../.. --schedule=./parallel_schedule --multibyte= == creating temporary installation== == initializing database system == == starting postmaster== running on port 65432 with pid 13106 == creating database "regression" == CREATE DATABASE == installing PL/pgSQL== == running regression test queries== parallel group (13 tests): text int4 oid boolean float8 int2 varchar float4 name int8 char bit numeric boolean ... ok char ... ok name ... ok varchar ... ok text ... ok int2 ... ok int4 ... ok int8 ... ok oid ... ok float4 ... ok float8 ... ok bit ... ok numeric ... ok test strings ... ok test numerology ... ok parallel group (18 tests): lseg point > ps -fu mhh mhh 12021 11904 0 10:19:27 ttyp3 0:00 gmake -C src/test check mhh 8026 1 0 09:17:08 ? 0:00 /usr/bin/X11/xterm -display 47.118.30.186:0 mhh 13155 12076 0 10:23:03 ttyp3 0:00 tee ./regression.out mhh 13328 13154 1 10:24:08 ttyp3 0:00 mhh 12076 12022 0 10:19:51 ttyp3 0:00 /bin/sh ./pg_regress --temp-install --top-builddir=../../.. mhh 8034 8026 0 09:17:11 ttyp3 0:00 /bnr/contrib/gnu/bin/bash --login mhh 13106 12076 0 10:22:50 ttyp3 0:00 /home/mhh/src/postgresql-7.1/src/test/regress/./tmp_check/in mhh 8810 1 0 09:28:45 ? 0:00 /usr/bin/X11/xterm -display 47.118.30.186:0 mhh 8811 8810 1 09:28:48 ttyp2 0:00 /bnr/contrib/gnu/bin/bash --login mhh 12022 12021 0 10:19:27 ttyp3 0:00 gmake -C regress check mhh 11904 8034 0 10:19:12 ttyp3 0:00 gmake check mhh 13154 12076 207 10:23:03 ttyp3 1:09 /bin/sh ./pg_regress --temp-install --top-builddir=../../.. - after killing the pg_regress --- > ps -fu mhh mhh 13358 8811 3 10:27:07 ttyp2 0:00 ps -fu mhh mhh 8026 1 0 09:17:08 ? 0:00 /usr/bin/X11/xterm -display 47.118.30.186:0 mhh 13328 13154 1 10:24:08 ttyp3 0:00 mhh 8034 8026 0 09:17:11 ttyp3 0:00 /bnr/contrib/gnu/bin/bash --login mhh 8810 1 0 09:28:45 ? 0:00 /usr/bin/X11/xterm -display 47.118.30.186:0 mhh 8811 8810 0 09:28:48 ttyp2 0:00 /bnr/contrib/gnu/bin/bash --login mhh 13154 1 253 10:23:03 ttyp3 2:55 /bin/sh ./pg_regress --temp-install --top-builddir=../../.. mhh 13326 13154 0 10:24:08 ttyp3 0:00 Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] 7.1 Build fails with Bash and CDPATH
I think we just patched this yesterday in CVS. > Mark Hollomon ([EMAIL PROTECTED]) reports a bug with a severity of 3 > The lower the number the more severe it is. > > Short Description > 7.1 Build fails with Bash and CDPATH > > Long Description > If using Bash with CDPATH set, the build of 7.1 fails with the following messages: > > gmake[2]: Entering directory `/home/mhh/src/postgresql-7.1/src/backend' > prereqdir=`cd parser/ && pwd` && \ > cd ../../src/include/parser/ && rm -f parse.h && \ > ln -s $prereqdir/parse.h . > ln: .//parser exists > gmake[2]: *** [../../src/include/parser/parse.h] Error 1 > gmake[2]: *** Deleting file `../../src/include/parser/parse.h' > gmake[2]: Leaving directory `/home/mhh/src/postgresql-7.1/src/backend' > gmake[1]: *** [all] Error 2 > gmake[1]: Leaving directory `/home/mhh/src/postgresql-7.1/src' > gmake: *** [all] Error 2 > > > I believe the following patch to backend/Makefile solves the problem: > > *** Makefile.orig Tue Apr 24 09:27:44 2001 > --- MakefileTue Apr 24 09:29:47 2001 > *** > *** 97,103 > # up to date when we update the base file. > > $(top_builddir)/src/include/parser/parse.h: $(srcdir)/parser/parse.h > ! prereqdir=`cd $(dir $<) && pwd` && \ > cd $(dir $@) && rm -f $(notdir $@) && \ > $(LN_S) $$prereqdir/$(notdir $<) . > > --- 97,103 > # up to date when we update the base file. > > $(top_builddir)/src/include/parser/parse.h: $(srcdir)/parser/parse.h > ! prereqdir=`cd $(dir $<) > /dev/null && pwd` && \ > cd $(dir $@) && rm -f $(notdir $@) && \ > $(LN_S) $$prereqdir/$(notdir $<) . > > > > > Sample Code > > > No file was uploaded with this report > > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] build of PL/Perl cannot find include files.
Mark Hollomon ([EMAIL PROTECTED]) reports a bug with a severity of 1 The lower the number the more severe it is. Short Description build of PL/Perl cannot find include files. Long Description HPUX 10.20 PostgreSQL 7.1 native compiler A build that includes PL/Perl fails with : gmake[1]: Entering directory `/home/mhh/src/postgresql-7.1/src/pl/plperl' cc -c -Ae -O +Onolimit-DVERSION=\"0.10\" -DXS_VERSION=\"0.10\" +z -I/home/u2/vobadm/perl5/lib/5.00503/PA-RISC1.1/CORE plperl.c cpp: "plperl.c", line 51: error 4036: Can't open include file 'executor/spi.h'. cpp: "plperl.c", line 52: error 4036: Can't open include file 'commands/trigger.h'. cpp: "plperl.c", line 53: error 4036: Can't open include file 'utils/elog.h'. cpp: "plperl.c", line 54: error 4036: Can't open include file 'fmgr.h'. cpp: "plperl.c", line 55: error 4036: Can't open include file 'access/heapam.h'. cpp: "plperl.c", line 57: error 4036: Can't open include file 'tcop/tcopprot.h'. cpp: "plperl.c", line 58: error 4036: Can't open include file 'utils/syscache.h'. cpp: "plperl.c", line 59: error 4036: Can't open include file 'catalog/pg_proc.h'. cpp: "plperl.c", line 60: error 4036: Can't open include file 'catalog/pg_type.h'. gmake[1]: *** [plperl.o] Error 1 Sample Code No file was uploaded with this report ---(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] incompatible return type for netmask(inet) function between 7.0.3 and 7.1
Hi Vadim, I don't know if this is of any help, but it might be... With PostgreSQL 7.0.x, there was a bug with the way inet type data was being returned. It was being given out as text, but with spaces used for padding stuck on the end of the string. i.e. '192.168.1.1 ' This was fixed in 7.1. i.e. '192.168.1.1' Depending on how you're doing things, you *might* be able to wrap stuff in a btrim() function for 7.0.x. i.e. btrim() should return '192.168.1.1' Well, you get the idea. Might be a start of a workaround for you anyway. Regards and best wishes, Justin Clift [EMAIL PROTECTED] wrote: > > Vadim Passynkov ([EMAIL PROTECTED]) reports a bug with a severity of 4 > The lower the number the more severe it is. > > Short Description > incompatible return type for netmask(inet) function between 7.0.3 and 7.1 > > Long Description > Function netmask(inet) change return type from 7.0.3 to 7.1 > In 7.0.3 return type was text, in 7.1 return type inet > Realy in 7.1 added text(inet) and of course need that > host and netmask have return type inet, but host in 7.1 still return > text. > > Other problem this changes that dump code from 7.0.3 incompatible > with 7.1. > > Sample Code > Version 7.0.3 > template1=# \df netmask >List of functions > Result | Function | Arguments > +--+--- > text | netmask | inet > (1 row) > > template1=# \df host >List of functions > Result | Function | Arguments > +--+--- > text | host | inet > (1 row) > > Version 7.1 > template1=# \df netmask >List of functions > Result | Function | Arguments > +--+--- > inet | netmask | inet > (1 row) > > template1=# \df host >List of functions > Result | Function | Arguments > +--+--- > text | host | inet > (1 row) > > No file was uploaded with this report > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(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] pg_regress hangs on parallel test
> Mark Hollomon ([EMAIL PROTECTED]) reports a bug with a severity of 2 > pg_regress hangs on parallel test > > Long Description > HPUX 10.20 > postgreSQL 7.1 FAQ_HPUX #5 -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(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] incompatible return type for netmask(inet) function between 7.0.3 and 7.1
Justin Clift wrote: > For 7.0.3 I already found solution for this problem, thanks. I ask now about why logical same functions host(inet) and netmask(inet) return different types ? > Hi Vadim, > > I don't know if this is of any help, but it might be... > > With PostgreSQL 7.0.x, there was a bug with the way inet type data was > being returned. It was being given out as text, but with spaces used > for padding stuck on the end of the string. > > i.e. '192.168.1.1 ' > > This was fixed in 7.1. > > i.e. '192.168.1.1' > > Depending on how you're doing things, you *might* be able to wrap stuff > in a btrim() function for 7.0.x. > > i.e. btrim() should return '192.168.1.1' > > Well, you get the idea. Might be a start of a workaround for you > anyway. > > Regards and best wishes, > > Justin Clift > > [EMAIL PROTECTED] wrote: > > > > Vadim Passynkov ([EMAIL PROTECTED]) reports a bug with a severity of 4 > > The lower the number the more severe it is. > > > > Short Description > > incompatible return type for netmask(inet) function between 7.0.3 and 7.1 > > > > Long Description > > Function netmask(inet) change return type from 7.0.3 to 7.1 > > In 7.0.3 return type was text, in 7.1 return type inet > > Realy in 7.1 added text(inet) and of course need that > > host and netmask have return type inet, but host in 7.1 still return > > text. > > > > Other problem this changes that dump code from 7.0.3 incompatible > > with 7.1. > > > > Sample Code > > Version 7.0.3 > > template1=# \df netmask > >List of functions > > Result | Function | Arguments > > +--+--- > > text | netmask | inet > > (1 row) > > > > template1=# \df host > >List of functions > > Result | Function | Arguments > > +--+--- > > text | host | inet > > (1 row) > > > > Version 7.1 > > template1=# \df netmask > >List of functions > > Result | Function | Arguments > > +--+--- > > inet | netmask | inet > > (1 row) > > > > template1=# \df host > >List of functions > > Result | Function | Arguments > > +--+--- > > text | host | inet > > (1 row) > > > > No file was uploaded with this report > > > > ---(end of broadcast)--- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > -- > "My grandfather once told me that there are two kinds of people: those > who work and those who take the credit. He told me to try to be in the > first group; there was less competition there." > - Indira Gandhi -- Vadim I. Passynkov, Axxent Corp. mailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
