Thread
-
Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T15:37:32Z
It is time for people to report their port testing. Please test against current CVS or beta5 and report your 'uname -a'. The current list is at: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Adam Witney <awitney@sghms.ac.uk> — 2003-10-24T15:48:37Z
On 24/10/03 4:37 pm, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. > > The current list is at: > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html All beta5 regression tests pass on [mrc1-003:] adam% uname -a Darwin mrc1-003.sghms.ac.uk 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC Power Macintosh powerpc [mrc1-003:] adam% sw_vers ProductName: Mac OS X ProductVersion: 10.2.8 BuildVersion: 6R73 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T15:57:34Z
Updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Adam Witney wrote: > On 24/10/03 4:37 pm, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > > > The current list is at: > > > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html > > All beta5 regression tests pass on > > [mrc1-003:] adam% uname -a > Darwin mrc1-003.sghms.ac.uk 6.8 Darwin Kernel Version 6.8: Wed Sep 10 > 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC Power Macintosh > powerpc > > [mrc1-003:] adam% sw_vers > ProductName: Mac OS X > ProductVersion: 10.2.8 > BuildVersion: 6R73 > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T16:23:58Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. Linux bell 2.4.22-1-k7 #5 Sat Oct 4 14:11:12 EST 2003 i686 GNU/Linux -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T16:25:09Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. Linux sparc-sid 2.4.22-ctx17a #1 SMP Sam Okt 11 23:39:04 CEST 2003 sparc64 GNU/Linux (32-bit build) -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T16:29:13Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > Linux bell 2.4.22-1-k7 #5 Sat Oct 4 14:11:12 EST 2003 i686 GNU/Linux > > -- > Peter Eisentraut peter_e@gmx.net > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T16:30:57Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > Linux sparc-sid 2.4.22-ctx17a #1 SMP Sam Okt 11 23:39:04 CEST 2003 sparc64 GNU/Linux > > (32-bit build) > > -- > Peter Eisentraut peter_e@gmx.net > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T16:42:04Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. FreeBSD svr1.postgresql.org 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #4: Sat Sep 20 14:41:58 ADT 2003 i386 -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T18:33:12Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. CYGWIN_NT-5.1 krusty 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 unknown unknown Cygwin I suggest that we change the operating system column for this platform from "Windows" to "Windows with Cygwin" and remove Cygwin from the comment column. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Marko Karppinen <marko@karppinen.fi> — 2003-10-24T18:39:41Z
On Oct 24, 2003, at 18:37, Bruce Momjian wrote: > It is time for people to report their port testing. Please test > against > current CVS or beta5 and report your 'uname -a'. This is with beta 5. Darwin marko.karppinen.fi 7.0.0 Darwin Kernel Version 7.0.0: Wed Sep 24 15:48:39 PDT 2003; root:xnu/xnu-517.obj~1/RELEASE_PPC Power Macintosh powerpc ProductName: Mac OS X ProductVersion: 10.3 BuildVersion: 7B85 6 out of 93 tests failed: date ... FAILED timetz ... FAILED inet ... FAILED comments ... FAILED test horology ... FAILED test misc ... FAILED The regression.diffs file is at: http://www.karppinen.fi/pgsql74b4-darwin7-regression.diffs mk -
Re: Call for port reports
Marko Karppinen <marko@karppinen.fi> — 2003-10-24T19:00:00Z
Looking a bit further into this, it looks like random tests are failing. Seems like an issue with the test harness on this platform. Does someone want a shell account to debug? mk On Oct 24, 2003, at 21:39, Marko Karppinen wrote: > 6 out of 93 tests failed: > date ... FAILED > timetz ... FAILED > inet ... FAILED > comments ... FAILED > test horology ... FAILED > test misc ... FAILED
-
Re: Call for port reports
Marko Karppinen <marko@karppinen.fi> — 2003-10-24T19:09:58Z
I'm just being an idiot, it's obviously a limits problem on the platform. It has a default max user processes limit of 100, which I was hitting. I shut down a bunch of desktop apps, and it's now passing: 92 of 93 tests passed, 1 failed test(s) ignored. (random was the one failing). So I guess you can add it to the list. mk
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T19:57:21Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. On True64 5.1 (no "thread safety" enabled) with gcc: In file included from postgresql-7.4beta5/src/port/thread.c:17: /usr/include/pthread.h:290:3: #error <pthread.h>: unrecognized compiler. /usr/include/pthread.h:328:4: #error "Please compile the module including pthread.h with -pthread" make[2]: *** [thread.o] Error 1 and analogously using vendor cc (only the second error). So this platform is officially broken right now. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T20:27:46Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. This one is OK: FreeBSD 4.8-RELEASE alpha BUT: The default CFLAGS are set by configure to -O2, although the template wants -O. I manually modified the CFLAGS to -O after configure. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports -- Failure on Linux
Rod Taylor <rbt@rbt.ca> — 2003-10-24T20:37:15Z
Linux ns2 2.4.20-xfs #2 Tue Apr 15 10:04:43 EDT 2003 i686 unknown <-- SNIP --> stats ... FAILED ============== shutting down postmaster ============== ======================= 1 of 93 tests failed. ======================= *** ./expected/stats.out Sat Sep 13 12:44:48 2003 --- ./results/stats.out Fri Oct 24 14:26:56 2003 *************** *** 8,14 **** SHOW stats_start_collector; -- must be on stats_start_collector ----------------------- ! on (1 row) -- save counters --- 8,14 ---- SHOW stats_start_collector; -- must be on stats_start_collector ----------------------- ! off (1 row) -- save counters *************** *** 62,68 **** WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? ----------+----------+----------+---------- ! t | t | t | t (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, --- 62,68 ---- WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? ----------+----------+----------+---------- ! f | f | f | f (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, *************** *** 71,77 **** WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? ----------+---------- ! t | t (1 row) -- clean up --- 71,77 ---- WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? ----------+---------- ! f | f (1 row) -- clean up On Fri, 2003-10-24 at 11:37, Bruce Momjian wrote: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. > > The current list is at: > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html -
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T20:37:22Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > FreeBSD svr1.postgresql.org 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #4: Sat Sep 20 14:41:58 ADT 2003 i386 > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T20:38:51Z
Heading updated too. Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > CYGWIN_NT-5.1 krusty 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 unknown unknown Cygwin > > I suggest that we change the operating system column for this platform > from "Windows" to "Windows with Cygwin" and remove Cygwin from the comment > column. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T20:45:19Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html I saw in your diff: ! psql: could not fork new process for connection: Resource temporarily unavailable so I figured it was something related to resources. --------------------------------------------------------------------------- Marko Karppinen wrote: > I'm just being an idiot, it's obviously a limits problem on the > platform. > It has a default max user processes limit of 100, which I was hitting. > I shut down a bunch of desktop apps, and it's now passing: > > 92 of 93 tests passed, 1 failed test(s) ignored. > (random was the one failing). > > So I guess you can add it to the list. > > mk > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 -
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T20:48:25Z
Thanks, fixed. Please retest. --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > On True64 5.1 (no "thread safety" enabled) with gcc: > > In file included from postgresql-7.4beta5/src/port/thread.c:17: > /usr/include/pthread.h:290:3: #error <pthread.h>: unrecognized compiler. > /usr/include/pthread.h:328:4: #error "Please compile the module including pthread.h with -pthread" > make[2]: *** [thread.o] Error 1 > > and analogously using vendor cc (only the second error). > > So this platform is officially broken right now. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T20:49:30Z
Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > This one is OK: > > FreeBSD 4.8-RELEASE alpha > > BUT: The default CFLAGS are set by configure to -O2, although the template > wants -O. I manually modified the CFLAGS to -O after configure. template/alpha has: case $host_cpu in alpha*) CFLAGS="$CFLAGS -O";; # alpha has problems with -O2 esac Is this not getting invoked? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T21:06:42Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. This one is OK: OpenBSD 3.2 GENERIC#25 i386 -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T21:10:06Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > This one is OK: > > OpenBSD 3.2 GENERIC#25 i386 > > -- > Peter Eisentraut peter_e@gmx.net > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T21:44:03Z
Bruce Momjian writes: > > BUT: The default CFLAGS are set by configure to -O2, although the template > > wants -O. I manually modified the CFLAGS to -O after configure. > > template/alpha has: > > case $host_cpu in > alpha*) CFLAGS="$CFLAGS -O";; # alpha has problems with -O2 > esac > > Is this not getting invoked? It appends it at the end, but apparently the result of '-02 ... -O' is -O2. So the compiler still yells at you every time that -O2 is broken in that platform. Right now, the default CFLAGS are pretty much broken on most platforms, so I'm testing by manually specifying the CFLAGS that should be used. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-24T21:46:31Z
Peter Eisentraut wrote: > Bruce Momjian writes: > > > > BUT: The default CFLAGS are set by configure to -O2, although the template > > > wants -O. I manually modified the CFLAGS to -O after configure. > > > > template/alpha has: > > > > case $host_cpu in > > alpha*) CFLAGS="$CFLAGS -O";; # alpha has problems with -O2 > > esac > > > > Is this not getting invoked? > > It appends it at the end, but apparently the result of '-02 ... -O' is > -O2. So the compiler still yells at you every time that -O2 is broken in > that platform. > > Right now, the default CFLAGS are pretty much broken on most platforms, so > I'm testing by manually specifying the CFLAGS that should be used. Wow, later optimization flags don't override earlier ones. Yikes! Does -O0 override an earlier -O2? I wonder if it is just complaining when it sees -O2 and is actually using -O for the compile. We still need to fix that, but I am curious. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Christopher Browne <cbbrowne@libertyrms.info> — 2003-10-24T21:55:24Z
pgman@candle.pha.pa.us (Bruce Momjian) writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. > > The current list is at: > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html ... Much omitted ... ============== shutting down postmaster ============== ====================== All 93 tests passed. ====================== rm regress.o make[1]: Leaving directory `/disk3/OXRS/pgsql-7.4-cvs/src/test/regress' postgres@ringo /disk3/OXRS/pgsql/src/test > uname -a SunOS ringo 5.8 Generic_108528-17 sun4u sparc SUNW,Ultra-4 That ought to "speak" at least somewhat for Solaris... I'm working on AIX, which is cascading in a bunch of additional toolchain (GNU M4, Bison, ...) -- (reverse (concatenate 'string "ofni.smrytrebil" "@" "enworbbc")) <http://dev6.int.libertyrms.com/> Christopher Browne (416) 646 3304 x124 (land)
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T21:58:44Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. This one is OK after the recent pthread.h patch: NetBSD 1.6 (GENERIC) i386 However, the compile pointed out that in src/interfaces/libpq/fe-auth.c line 472, variable "cmsg" is unused; and indeed it seems to be right. Bruce, you worked most often on the peer authentication code, so maybe you can check that. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports -- Failure on Linux
Robert Treat <xzilla@users.sourceforge.net> — 2003-10-24T22:00:34Z
worked fine on slackware: ====================== All 93 tests passed. ====================== Linux phppgadmin 2.4.18 #2 Fri May 31 01:21:23 PDT 2002 i586 unknown oh... different kernel, different filesystem.... Robert Treat On Fri, 2003-10-24 at 16:37, Rod Taylor wrote: > Linux ns2 2.4.20-xfs #2 Tue Apr 15 10:04:43 EDT 2003 i686 unknown > > <-- SNIP --> > stats ... FAILED > ============== shutting down postmaster ============== > > ======================= > 1 of 93 tests failed. > ======================= > > > *** ./expected/stats.out Sat Sep 13 12:44:48 2003 > --- ./results/stats.out Fri Oct 24 14:26:56 2003 > *************** > *** 8,14 **** > SHOW stats_start_collector; -- must be on > stats_start_collector > ----------------------- > ! on > (1 row) > > -- save counters > --- 8,14 ---- > SHOW stats_start_collector; -- must be on > stats_start_collector > ----------------------- > ! off > (1 row) > > -- save counters > *************** > *** 62,68 **** > WHERE st.relname='tenk2' AND cl.relname='tenk2'; > ?column? | ?column? | ?column? | ?column? > ----------+----------+----------+---------- > ! t | t | t | t > (1 row) > > SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + > cl.relpages, > --- 62,68 ---- > WHERE st.relname='tenk2' AND cl.relname='tenk2'; > ?column? | ?column? | ?column? | ?column? > ----------+----------+----------+---------- > ! f | f | f | f > (1 row) > > SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + > cl.relpages, > *************** > *** 71,77 **** > WHERE st.relname='tenk2' AND cl.relname='tenk2'; > ?column? | ?column? > ----------+---------- > ! t | t > (1 row) > > -- clean up > --- 71,77 ---- > WHERE st.relname='tenk2' AND cl.relname='tenk2'; > ?column? | ?column? > ----------+---------- > ! f | f > (1 row) > > -- clean up > > > > > On Fri, 2003-10-24 at 11:37, Bruce Momjian wrote: > > It is time for people to report their port testing. Please test > against > > current CVS or beta5 and report your 'uname -a'. > > > > The current list is at: > > > > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.htm > l -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL -
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T22:04:14Z
Bruce Momjian writes: > Does -O0 override an earlier -O2? I wonder if it is just complaining > when it sees -O2 and is actually using -O for the compile. We still > need to fix that, but I am curious. If you specify -O2 anywhere and the compile step is invoked (for example, you're not just preprocessing or just linking), then the warning is issued. However, further investigation showed that the last optimization option on the command line is the one that is actually used to perform the optimizations. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Chris Browne <cbbrowne@acm.org> — 2003-10-24T22:07:40Z
In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. > > The current list is at: > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html On AIX, it's _close_... ============== shutting down postmaster ============== ======================= 1 of 93 tests failed. ======================= bash-2.05a$ uname -a AIX ibm-db 1 5 000CD13A4C00 The difference lies here: bash-2.05a$ more regress/regression.diffs *** ./expected/errors.out Wed Oct 1 17:07:24 2003 --- ./results/errors.out Fri Oct 24 17:56:34 2003 *************** *** 197,211 **** ERROR: syntax error at or near ")" at character 20 -- no such operator drop operator === (int4); ! ERROR: missing argument ! HINT: Use NONE to denote the missing argument of a unary operator. -- no such operator by that name drop operator === (int4, int4); ERROR: operator does not exist: integer === integer -- no such type1 drop operator = (nonesuch); ! ERROR: missing argument ! HINT: Use NONE to denote the missing argument of a unary operator. -- no such type1 drop operator = ( , int4); ERROR: syntax error at or near "," at character 19 --- 197,209 ---- ERROR: syntax error at or near ")" at character 20 -- no such operator drop operator === (int4); ! ERROR: argument type missing (use NONE for unary operators) -- no such operator by that name drop operator === (int4, int4); ERROR: operator does not exist: integer === integer -- no such type1 drop operator = (nonesuch); ! ERROR: argument type missing (use NONE for unary operators) -- no such type1 drop operator = ( , int4); ERROR: syntax error at or near "," at character 19 ====================================================================== I'll have to look at "why" next week; I don't see the dropping of a HINT message being a dramatic error, though. -- (format nil "~S@~S" "cbbrowne" "cbbrowne.com") http://cbbrowne.com/info/spreadsheets.html "And if you could lie on the floor without holding on, you weren't really drunk :-)" -- Preben Guldberg <c928400@student.dtu.dk>
-
Re: Call for port reports
Kurt Roeckx <q@ping.be> — 2003-10-24T22:24:31Z
On Fri, Oct 24, 2003 at 11:37:32AM -0400, Bruce Momjian wrote: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. I need this small patch so it properly detects I have unix domain sockets. Otherwise no problems. Kurt
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T22:46:39Z
Kurt Roeckx writes: > On Fri, Oct 24, 2003 at 11:37:32AM -0400, Bruce Momjian wrote: > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > I need this small patch so it properly detects I have unix domain > sockets. Otherwise no problems. What system? What happens without the patch? Details, please. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Alvaro Herrera <alvherre@dcc.uchile.cl> — 2003-10-24T22:56:29Z
On Fri, Oct 24, 2003 at 06:07:40PM -0400, Christopher Browne wrote: > In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote: > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > > > The current list is at: > > > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html > > On AIX, it's _close_... That message was reworded early in the beta cycle IIRC ... maybe you have some old "expected" files lying around? > ! ERROR: missing argument > ! HINT: Use NONE to denote the missing argument of a unary operator. > --- 197,209 ---- > ! ERROR: argument type missing (use NONE for unary operators) -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Ciencias políticas es la ciencia de entender por qué los políticos actúan como lo hacen" (netfunny.com)
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-24T23:20:13Z
Bruce Momjian writes: > Thanks, fixed. Please retest. I get farther, but I'm getting failures in the stats test that were reported by earlier posters as well. In the server log I see: LOG: could not bind socket for statistics collector: Can't assign requested address What could be the cause of this? Also, using vendor cc I have to add the option -ieee, else it won't accept 0.0/0.0. This was also reported for earlier releases but never put into our source. I intend to do that unless someone objects. > --------------------------------------------------------------------------- > > Peter Eisentraut wrote: > > Bruce Momjian writes: > > > > > It is time for people to report their port testing. Please test against > > > current CVS or beta5 and report your 'uname -a'. > > > > On True64 5.1 (no "thread safety" enabled) with gcc: > > > > In file included from postgresql-7.4beta5/src/port/thread.c:17: > > /usr/include/pthread.h:290:3: #error <pthread.h>: unrecognized compiler. > > /usr/include/pthread.h:328:4: #error "Please compile the module including pthread.h with -pthread" > > make[2]: *** [thread.o] Error 1 > > > > and analogously using vendor cc (only the second error). > > > > So this platform is officially broken right now. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Kurt Roeckx <q@ping.be> — 2003-10-24T23:25:25Z
On Sat, Oct 25, 2003 at 12:46:39AM +0200, Peter Eisentraut wrote: > Kurt Roeckx writes: > > > I need this small patch so it properly detects I have unix domain > > sockets. Otherwise no problems. > > What system? What happens without the patch? Details, please. It's a Linux system with libc5. during configure: checking sys/un.h usability... no checking sys/un.h presence... yes configure: WARNING: sys/un.h: present but cannot be compiled configure: WARNING: sys/un.h: check for missing prerequisite headers? configure: WARNING: sys/un.h: proceeding with the preprocessor's result ... checking for struct sockaddr_un... no With a newer autoconf this turns into: checking sys/un.h usability... no checking sys/un.h presence... yes configure: WARNING: sys/un.h: present but cannot be compiled configure: WARNING: sys/un.h: check for missing prerequisite headers? configure: WARNING: sys/un.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for sys/un.h... yes I did report it to them, and they told me to fix the configure.in. It compiles fine, runs fine. It just then has a problem with the regression test because there it checks the OS to decide if it has unix domain sockets or not. Manualy fixing the script fixes that problem. (I think it's somewhere in the TODO to fix this.) Kurt
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-25T03:17:26Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Christopher Browne wrote: > pgman@candle.pha.pa.us (Bruce Momjian) writes: > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > > > The current list is at: > > > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html > > ... Much omitted ... > ============== shutting down postmaster ============== > > ====================== > All 93 tests passed. > ====================== > > rm regress.o > make[1]: Leaving directory `/disk3/OXRS/pgsql-7.4-cvs/src/test/regress' > postgres@ringo /disk3/OXRS/pgsql/src/test > uname -a > SunOS ringo 5.8 Generic_108528-17 sun4u sparc SUNW,Ultra-4 > > That ought to "speak" at least somewhat for Solaris... > > I'm working on AIX, which is cascading in a bunch of additional > toolchain (GNU M4, Bison, ...) > -- > (reverse (concatenate 'string "ofni.smrytrebil" "@" "enworbbc")) > <http://dev6.int.libertyrms.com/> > Christopher Browne > (416) 646 3304 x124 (land) > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-25T03:51:36Z
Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > This one is OK after the recent pthread.h patch: > > NetBSD 1.6 (GENERIC) i386 > > However, the compile pointed out that in src/interfaces/libpq/fe-auth.c > line 472, variable "cmsg" is unused; and indeed it seems to be right. > Bruce, you worked most often on the peer authentication code, so maybe you > can check that. Not sure why those variable defines are there --- they aren't referenced anywhere in that function when HAVE_STRUCT_SOCKCRED is also defined. I removed that code. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Hans-Jürgen Schönig <hs@cybertec.at> — 2003-10-25T07:28:51Z
Regression testing on AIX 5 using 7.4beta5: polymorphism ... ok stats ... ok ============== shutting down postmaster ============== ====================== All 93 tests passed. ====================== bash-2.05$ uname -a AIX sn2 1 5 0044276A4C00 checking build system type... powerpc-ibm-aix5.1.0.0 checking host system type... powerpc-ibm-aix5.1.0.0 checking which template to use... aix bash-2.05$ gcc -v Reading specs from /usr/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix43-010414/specs gcc version 2.9-aix43-010414 Good work :) Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706 or +43/660/816 40 77 www.cybertec.at, www.postgresql.at, kernel.cybertec.at -
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-25T09:18:45Z
Bruce Momjian writes: > > BUT: The default CFLAGS are set by configure to -O2, although the template > > wants -O. I manually modified the CFLAGS to -O after configure. > > template/alpha has: > > case $host_cpu in > alpha*) CFLAGS="$CFLAGS -O";; # alpha has problems with -O2 > esac > > Is this not getting invoked? After further consideration, I think that the recent patch series that tried to centralize the CFLAGS handling in configure should be reverted to configure.in revision 1.293. Otherwise, it's much to complicated to handle all the special cases. There is, after all, a reason we have been forced to keep it this way all these years. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Kurt Roeckx <q@ping.be> — 2003-10-25T11:33:34Z
On Fri, Oct 24, 2003 at 11:37:32AM -0400, Bruce Momjian wrote: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. checking build system type... i386-pc-solaris2.6 checking host system type... i386-pc-solaris2.6 checking which template to use... solaris [...] checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes [...] checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes configure: using CFLAGS=-g -O2 -fno-strict-aliasing checking whether the C compiler still works... no configure: error: cannot proceed oink% gcc -v Reading specs from /usr/local/lib/gcc-lib/i386-pc-solaris2.6/2.8.1/specs gcc version 2.8.1 CFLAGS="-g -O2" ./configure --without-readline [...] ====================== All 93 tests passed. ====================== Kurt
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-25T14:00:59Z
Peter Eisentraut wrote: > Bruce Momjian writes: > > > > BUT: The default CFLAGS are set by configure to -O2, although the template > > > wants -O. I manually modified the CFLAGS to -O after configure. > > > > template/alpha has: > > > > case $host_cpu in > > alpha*) CFLAGS="$CFLAGS -O";; # alpha has problems with -O2 > > esac > > > > Is this not getting invoked? > > After further consideration, I think that the recent patch series that > tried to centralize the CFLAGS handling in configure should be reverted to > configure.in revision 1.293. Otherwise, it's much to complicated to > handle all the special cases. There is, after all, a reason we have been > forced to keep it this way all these years. Remember the old code had CFLAGS="" in lots of platforms, meaning they got no optimization. It seems right now Alpha is our only problem, and it is really just a message problem because the later flags override the earlier ones. Why can't get just remove -O2 from the alpha CFLAGS line via makefile magic? Frankly, we could just do CFLAGS="-O" and be done with it because we would not be bringing in the -O2, but I would rather keep it clean and remove just -O2. I don't think going backwards is a good solution because it spreads the problem down to the templates again. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Larry Rosenman <ler@lerctr.org> — 2003-10-25T14:11:43Z
--On Saturday, October 25, 2003 10:00:59 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Peter Eisentraut wrote: >> Bruce Momjian writes: >> >> > > BUT: The default CFLAGS are set by configure to -O2, although the >> > > template wants -O. I manually modified the CFLAGS to -O after >> > > configure. >> > >> > template/alpha has: >> > >> > case $host_cpu in >> > alpha*) CFLAGS="$CFLAGS -O";; # alpha has problems with -O2 >> > esac >> > >> > Is this not getting invoked? >> >> After further consideration, I think that the recent patch series that >> tried to centralize the CFLAGS handling in configure should be reverted >> to configure.in revision 1.293. Otherwise, it's much to complicated to >> handle all the special cases. There is, after all, a reason we have been >> forced to keep it this way all these years. > > Remember the old code had CFLAGS="" in lots of platforms, meaning they > got no optimization. > > It seems right now Alpha is our only problem, and it is really just a > message problem because the later flags override the earlier ones. Why > can't get just remove -O2 from the alpha CFLAGS line via makefile magic? > Frankly, we could just do CFLAGS="-O" and be done with it because we > would not be bringing in the -O2, but I would rather keep it clean and > remove just -O2. We also get -g on UnixWare cc (NOT gcc) builds, which we didn't before, which means we do NOT get optimization (UnixWare's cc doesn't like -O and -g together). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-25T14:12:50Z
Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian writes: > > > > > > BUT: The default CFLAGS are set by configure to -O2, although the template > > > > wants -O. I manually modified the CFLAGS to -O after configure. > > > > > > template/alpha has: > > > > > > case $host_cpu in > > > alpha*) CFLAGS="$CFLAGS -O";; # alpha has problems with -O2 > > > esac > > > > > > Is this not getting invoked? > > > > After further consideration, I think that the recent patch series that > > tried to centralize the CFLAGS handling in configure should be reverted to > > configure.in revision 1.293. Otherwise, it's much to complicated to > > handle all the special cases. There is, after all, a reason we have been > > forced to keep it this way all these years. > > Remember the old code had CFLAGS="" in lots of platforms, meaning they > got no optimization. > > It seems right now Alpha is our only problem, and it is really just a > message problem because the later flags override the earlier ones. Why > can't get just remove -O2 from the alpha CFLAGS line via makefile magic? > Frankly, we could just do CFLAGS="-O" and be done with it because we > would not be bringing in the -O2, but I would rather keep it clean and > remove just -O2. > > I don't think going backwards is a good solution because it spreads the > problem down to the templates again. In fact, another question is why this alpha test is only done in freebsd? Certainly other alpha gcc platforms must have problems with -O2? I am inclined to add something to configure.in for all alpha compiles that changes -O2 to -O. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-25T14:14:14Z
Larry Rosenman wrote: > >> After further consideration, I think that the recent patch series that > >> tried to centralize the CFLAGS handling in configure should be reverted > >> to configure.in revision 1.293. Otherwise, it's much to complicated to > >> handle all the special cases. There is, after all, a reason we have been > >> forced to keep it this way all these years. > > > > Remember the old code had CFLAGS="" in lots of platforms, meaning they > > got no optimization. > > > > It seems right now Alpha is our only problem, and it is really just a > > message problem because the later flags override the earlier ones. Why > > can't get just remove -O2 from the alpha CFLAGS line via makefile magic? > > Frankly, we could just do CFLAGS="-O" and be done with it because we > > would not be bringing in the -O2, but I would rather keep it clean and > > remove just -O2. > We also get -g on UnixWare cc (NOT gcc) builds, which we didn't before, > which means we do NOT get optimization (UnixWare's cc doesn't like > -O and -g together). We are going to fix that, but what happens? Does the compile fail or does optimization just get turned off? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-25T14:23:49Z
Bruce Momjian writes: > In fact, another question is why this alpha test is only done in > freebsd? Ask that to the maintainers of the FreeBSD system compiler. > Certainly other alpha gcc platforms must have problems with -O2? > I am inclined to add something to configure.in for all alpha compiles > that changes -O2 to -O. I'm not. It's one thing if FreeBSD thinks their compiler is broken. But before I accept that gcc is broken as a whole, I want to hear from the GCC folks. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Larry Rosenman <ler@lerctr.org> — 2003-10-25T14:25:21Z
--On Saturday, October 25, 2003 10:14:14 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Larry Rosenman wrote: >> >> After further consideration, I think that the recent patch series that >> >> tried to centralize the CFLAGS handling in configure should be >> >> reverted to configure.in revision 1.293. Otherwise, it's much to >> >> complicated to handle all the special cases. There is, after all, a >> >> reason we have been forced to keep it this way all these years. >> > >> > Remember the old code had CFLAGS="" in lots of platforms, meaning they >> > got no optimization. >> > >> > It seems right now Alpha is our only problem, and it is really just a >> > message problem because the later flags override the earlier ones. Why >> > can't get just remove -O2 from the alpha CFLAGS line via makefile >> > magic? Frankly, we could just do CFLAGS="-O" and be done with it >> > because we would not be bringing in the -O2, but I would rather keep >> > it clean and remove just -O2. >> We also get -g on UnixWare cc (NOT gcc) builds, which we didn't before, >> which means we do NOT get optimization (UnixWare's cc doesn't like >> -O and -g together). > > We are going to fix that, but what happens? Does the compile fail or > does optimization just get turned off? just a warning on each compile and no optimization. LER > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania > 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-25T14:47:32Z
Peter Eisentraut wrote: > Bruce Momjian writes: > > > In fact, another question is why this alpha test is only done in > > freebsd? > > Ask that to the maintainers of the FreeBSD system compiler. > > > Certainly other alpha gcc platforms must have problems with -O2? > > I am inclined to add something to configure.in for all alpha compiles > > that changes -O2 to -O. > > I'm not. It's one thing if FreeBSD thinks their compiler is broken. But > before I accept that gcc is broken as a whole, I want to hear from the GCC > folks. Oh, so it is only FreeBSD that emits that warning. Interesting. I haven't seen that error from any other platform, so you must be right. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-25T15:45:47Z
Peter Eisentraut wrote: > Bruce Momjian writes: > > > In fact, another question is why this alpha test is only done in > > freebsd? > > Ask that to the maintainers of the FreeBSD system compiler. > > > Certainly other alpha gcc platforms must have problems with -O2? > > I am inclined to add something to configure.in for all alpha compiles > > that changes -O2 to -O. > > I'm not. It's one thing if FreeBSD thinks their compiler is broken. But > before I accept that gcc is broken as a whole, I want to hear from the GCC > folks. How does everyone like this patch? It removes -g from non-debug compiles, and changes -O2 to -O for FreeBSD/Alpha. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-25T16:35:06Z
Peter Eisentraut writes: > FreeBSD 4.8-RELEASE alpha > > BUT: The default CFLAGS are set by configure to -O2, although the template > wants -O. I manually modified the CFLAGS to -O after configure. I've committed a fix for the CFLAGS handling, and now this platform works perfectly. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Larry Rosenman <ler@lerctr.org> — 2003-10-25T17:06:37Z
--On Saturday, October 25, 2003 18:35:06 +0200 Peter Eisentraut <peter_e@gmx.net> wrote: > Peter Eisentraut writes: > >> FreeBSD 4.8-RELEASE alpha >> >> BUT: The default CFLAGS are set by configure to -O2, although the >> template wants -O. I manually modified the CFLAGS to -O after configure. > > I've committed a fix for the CFLAGS handling, and now this platform works > perfectly. That commit also fixed my -g issue with UnixWare. I still have the following regression.diffs: *** ./expected/privileges.out Thu Oct 9 20:49:31 2003 --- ./results/privileges.out Sat Oct 25 12:04:45 2003 *************** *** 247,253 **** (1 row) CREATE FUNCTION testfunc3(int) RETURNS int AS 'select 2 * $1;' LANGUAGE sql; -- fail - ERROR: permission denied for language sql SET SESSION AUTHORIZATION regressuser3; SELECT testfunc1(5); -- fail ERROR: permission denied for function testfunc1 --- 247,252 ---- ====================================================================== > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-25T20:24:14Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. After the just-committed fix, Tru64 5.1 alpha is OK with both cc and gcc. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-25T20:29:04Z
Larry Rosenman writes: > *** ./expected/privileges.out Thu Oct 9 20:49:31 2003 > --- ./results/privileges.out Sat Oct 25 12:04:45 2003 > *************** > *** 247,253 **** > (1 row) > > CREATE FUNCTION testfunc3(int) RETURNS int AS 'select 2 * $1;' LANGUAGE > sql; -- fail > - ERROR: permission denied for language sql > SET SESSION AUTHORIZATION regressuser3; > SELECT testfunc1(5); -- fail > ERROR: permission denied for function testfunc1 > --- 247,252 ---- That sounds extremely strange. Can you step through the privileges.sql file manually (psql single-step mode) and check what the contents of pg_language, pg_shadow, current_user, and session_user are before the misbehaving command? -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-25T21:33:16Z
Kurt Roeckx writes: > configure: using CFLAGS=-g -O2 -fno-strict-aliasing > checking whether the C compiler still works... no > configure: error: cannot proceed > oink% gcc -v > Reading specs from > /usr/local/lib/gcc-lib/i386-pc-solaris2.6/2.8.1/specs > gcc version 2.8.1 > > CFLAGS="-g -O2" ./configure --without-readline I've installed a detection logic that finds out whether -fno-strict-aliasing works. Please give it a quick run through, then we check this platform off. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Larry Rosenman <ler@lerctr.org> — 2003-10-25T21:37:52Z
--On Saturday, October 25, 2003 22:29:04 +0200 Peter Eisentraut <peter_e@gmx.net> wrote: > Larry Rosenman writes: > >> *** ./expected/privileges.out Thu Oct 9 20:49:31 2003 >> --- ./results/privileges.out Sat Oct 25 12:04:45 2003 >> *************** >> *** 247,253 **** >> (1 row) >> >> CREATE FUNCTION testfunc3(int) RETURNS int AS 'select 2 * $1;' LANGUAGE >> sql; -- fail >> - ERROR: permission denied for language sql >> SET SESSION AUTHORIZATION regressuser3; >> SELECT testfunc1(5); -- fail >> ERROR: permission denied for function testfunc1 >> --- 247,252 ---- > > That sounds extremely strange. Can you step through the privileges.sql > file manually (psql single-step mode) and check what the contents of > pg_language, pg_shadow, current_user, and session_user are before the > misbehaving command? > > -- > Peter Eisentraut peter_e@gmx.net here ya go: Script started on Sat Oct 25 16:34:24 2003 $ psql -s reg? ?? ?? ?-U p? ?ler regression Welcome to psql 7.4beta5, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit regression=# \i privileges.sql ***(Single step mode: verify command)******************************************* CREATE USER regressuser1; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:5: ERROR: user "regressuser1" already exists ***(Single step mode: verify command)******************************************* CREATE USER regressuser2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:6: ERROR: user "regressuser2" already exists ***(Single step mode: verify command)******************************************* CREATE USER regressuser3; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:7: ERROR: user "regressuser3" already exists ***(Single step mode: verify command)******************************************* CREATE USER regressuser4; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:8: ERROR: user "regressuser4" already exists ***(Single step mode: verify command)******************************************* CREATE USER regressuser4; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:9: ERROR: user "regressuser4" already exists ***(Single step mode: verify command)******************************************* CREATE GROUP regressgroup1; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:11: ERROR: group "regressgroup1" already exists ***(Single step mode: verify command)******************************************* CREATE GROUP regressgroup2 WITH USER regressuser1, regressuser2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:12: ERROR: group "regressgroup2" already exists ***(Single step mode: verify command)******************************************* ALTER GROUP regressgroup1 ADD USER regressuser4; ***(press return to proceed or enter x and return to cancel)******************** ALTER GROUP ***(Single step mode: verify command)******************************************* ALTER GROUP regressgroup2 ADD USER regressuser2; ***(press return to proceed or enter x and return to cancel)******************** ALTER GROUP ***(Single step mode: verify command)******************************************* ALTER GROUP regressgroup2 DROP USER regressuser2; ***(press return to proceed or enter x and return to cancel)******************** ALTER GROUP ***(Single step mode: verify command)******************************************* ALTER GROUP regressgroup2 ADD USER regressuser4; ***(press return to proceed or enter x and return to cancel)******************** ALTER GROUP ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser1; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* SELECT session_user, current_user; ***(press return to proceed or enter x and return to cancel)******************** session_user | current_user --------------+-------------- regressuser1 | regressuser1 (1 row) ***(Single step mode: verify command)******************************************* CREATE TABLE atest1 ( a int, b text ); ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:26: ERROR: relation "atest1" already exists ***(Single step mode: verify command)******************************************* SELECT * FROM atest1; ***(press return to proceed or enter x and return to cancel)******************** a | b ---+----- 1 | two 1 | two (2 rows) ***(Single step mode: verify command)******************************************* INSERT INTO atest1 VALUES (1, 'one'); ***(press return to proceed or enter x and return to cancel)******************** INSERT 2356104 1 ***(Single step mode: verify command)******************************************* DELETE FROM atest1; ***(press return to proceed or enter x and return to cancel)******************** DELETE 3 ***(Single step mode: verify command)******************************************* UPDATE atest1 SET a = 1 WHERE b = 'blech'; ***(press return to proceed or enter x and return to cancel)******************** UPDATE 0 ***(Single step mode: verify command)******************************************* LOCK atest1 IN ACCESS EXCLUSIVE MODE; ***(press return to proceed or enter x and return to cancel)******************** LOCK TABLE ***(Single step mode: verify command)******************************************* REVOKE ALL ON atest1 FROM PUBLIC; ***(press return to proceed or enter x and return to cancel)******************** REVOKE ***(Single step mode: verify command)******************************************* SELECT * FROM atest1; ***(press return to proceed or enter x and return to cancel)******************** a | b ---+--- (0 rows) ***(Single step mode: verify command)******************************************* GRANT ALL ON atest1 TO regressuser2; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* GRANT SELECT ON atest1 TO regressuser3, regressuser4; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* SELECT * FROM atest1; ***(press return to proceed or enter x and return to cancel)******************** a | b ---+--- (0 rows) ***(Single step mode: verify command)******************************************* CREATE TABLE atest2 (col1 varchar(10), col2 boolean); ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:40: ERROR: relation "atest2" already exists ***(Single step mode: verify command)******************************************* GRANT SELECT ON atest2 TO regressuser2; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* GRANT UPDATE ON atest2 TO regressuser3; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* GRANT INSERT ON atest2 TO regressuser4; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser2; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* SELECT session_user, current_user; ***(press return to proceed or enter x and return to cancel)******************** session_user | current_user --------------+-------------- regressuser2 | regressuser2 (1 row) ***(Single step mode: verify command)******************************************* SELECT * FROM atest1; ***(press return to proceed or enter x and return to cancel)******************** a | b ---+--- (0 rows) ***(Single step mode: verify command)******************************************* SELECT * FROM atest2; ***(press return to proceed or enter x and return to cancel)******************** col1 | col2 ------+------ bar | t (1 row) ***(Single step mode: verify command)******************************************* INSERT INTO atest1 VALUES (2, 'two'); ***(press return to proceed or enter x and return to cancel)******************** INSERT 2356105 1 ***(Single step mode: verify command)******************************************* INSERT INTO atest2 VALUES ('foo', true); ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:54: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* INSERT INTO atest1 SELECT 1, b FROM atest1; ***(press return to proceed or enter x and return to cancel)******************** INSERT 2356106 1 ***(Single step mode: verify command)******************************************* UPDATE atest1 SET a = 1 WHERE a = 2; ***(press return to proceed or enter x and return to cancel)******************** UPDATE 1 ***(Single step mode: verify command)******************************************* UPDATE atest2 SET col2 = NOT col2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:57: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* SELECT * FROM atest1 FOR UPDATE; ***(press return to proceed or enter x and return to cancel)******************** a | b ---+----- 1 | two 1 | two (2 rows) ***(Single step mode: verify command)******************************************* SELECT * FROM atest2 FOR UPDATE; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:59: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* DELETE FROM atest2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:60: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* LOCK atest2 IN ACCESS EXCLUSIVE MODE; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:61: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* COPY atest2 FROM stdin; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:62: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* GRANT ALL ON atest1 TO PUBLIC; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:63: ERROR: permission denied for relation atest1 ***(Single step mode: verify command)******************************************* SELECT * FROM atest1 WHERE ( b IN ( SELECT col1 FROM atest2 ) ); ***(press return to proceed or enter x and return to cancel)******************** a | b ---+--- (0 rows) ***(Single step mode: verify command)******************************************* SELECT * FROM atest2 WHERE ( col1 IN ( SELECT b FROM atest1 ) ); ***(press return to proceed or enter x and return to cancel)******************** col1 | col2 ------+------ (0 rows) ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser3; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* SELECT session_user, current_user; ***(press return to proceed or enter x and return to cancel)******************** session_user | current_user --------------+-------------- regressuser3 | regressuser3 (1 row) ***(Single step mode: verify command)******************************************* SELECT * FROM atest1; ***(press return to proceed or enter x and return to cancel)******************** a | b ---+----- 1 | two 1 | two (2 rows) ***(Single step mode: verify command)******************************************* SELECT * FROM atest2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:74: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* INSERT INTO atest1 VALUES (2, 'two'); ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:75: ERROR: permission denied for relation atest1 ***(Single step mode: verify command)******************************************* INSERT INTO atest2 VALUES ('foo', true); ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:76: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* INSERT INTO atest1 SELECT 1, b FROM atest1; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:77: ERROR: permission denied for relation atest1 ***(Single step mode: verify command)******************************************* UPDATE atest1 SET a = 1 WHERE a = 2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:78: ERROR: permission denied for relation atest1 ***(Single step mode: verify command)******************************************* UPDATE atest2 SET col2 = NULL; ***(press return to proceed or enter x and return to cancel)******************** UPDATE 1 ***(Single step mode: verify command)******************************************* UPDATE atest2 SET col2 = NOT col2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:80: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* UPDATE atest2 SET col2 = true WHERE atest1.a = 5; ***(press return to proceed or enter x and return to cancel)******************** UPDATE 0 ***(Single step mode: verify command)******************************************* SELECT * FROM atest1 FOR UPDATE; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:82: ERROR: permission denied for relation atest1 ***(Single step mode: verify command)******************************************* SELECT * FROM atest2 FOR UPDATE; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:83: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* DELETE FROM atest2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:84: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* LOCK atest2 IN ACCESS EXCLUSIVE MODE; ***(press return to proceed or enter x and return to cancel)******************** LOCK TABLE ***(Single step mode: verify command)******************************************* COPY atest2 FROM stdin; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:86: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* SELECT * FROM atest1 WHERE ( b IN ( SELECT col1 FROM atest2 ) ); ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:89: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* SELECT * FROM atest2 WHERE ( col1 IN ( SELECT b FROM atest1 ) ); ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:90: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser4; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* COPY atest2 FROM stdin; ***(press return to proceed or enter x and return to cancel)******************** ***(Single step mode: verify command)******************************************* SELECT * FROM atest1; ***(press return to proceed or enter x and return to cancel)******************** a | b ---+----- 1 | two 1 | two (2 rows) ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser3; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* CREATE TABLE atest3 (one int, two int, three int); ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:102: ERROR: relation "atest3" already exists ***(Single step mode: verify command)******************************************* GRANT DELETE ON atest3 TO GROUP regressgroup2; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser1; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* SELECT * FROM atest3; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:107: ERROR: permission denied for relation atest3 ***(Single step mode: verify command)******************************************* DELETE FROM atest3; ***(press return to proceed or enter x and return to cancel)******************** DELETE 0 ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser3; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* CREATE VIEW atestv1 AS SELECT * FROM atest1; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:115: ERROR: relation "atestv1" already exists ***(Single step mode: verify command)******************************************* /* The next *should* fail, but it's not implemented that way yet. */ CREATE VIEW atestv2 AS SELECT * FROM atest2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:117: ERROR: relation "atestv2" already exists ***(Single step mode: verify command)******************************************* CREATE VIEW atestv3 AS SELECT * FROM atest3; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:118: ERROR: relation "atestv3" already exists ***(Single step mode: verify command)******************************************* SELECT * FROM atestv1; ***(press return to proceed or enter x and return to cancel)******************** a | b ---+----- 1 | two 1 | two (2 rows) ***(Single step mode: verify command)******************************************* SELECT * FROM atestv2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:121: ERROR: permission denied for relation atest2 ***(Single step mode: verify command)******************************************* GRANT SELECT ON atestv1, atestv3 TO regressuser4; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* GRANT SELECT ON atestv2 TO regressuser2; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser4; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* SELECT * FROM atestv1; ***(press return to proceed or enter x and return to cancel)******************** a | b ---+----- 1 | two 1 | two (2 rows) ***(Single step mode: verify command)******************************************* SELECT * FROM atestv2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:128: ERROR: permission denied for relation atestv2 ***(Single step mode: verify command)******************************************* SELECT * FROM atestv3; ***(press return to proceed or enter x and return to cancel)******************** one | two | three -----+-----+------- (0 rows) ***(Single step mode: verify command)******************************************* CREATE VIEW atestv4 AS SELECT * FROM atestv3; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:131: ERROR: relation "atestv4" already exists ***(Single step mode: verify command)******************************************* SELECT * FROM atestv4; ***(press return to proceed or enter x and return to cancel)******************** one | two | three -----+-----+------- (0 rows) ***(Single step mode: verify command)******************************************* GRANT SELECT ON atestv4 TO regressuser2; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser2; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* SELECT * FROM atestv3; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:139: ERROR: permission denied for relation atestv3 ***(Single step mode: verify command)******************************************* SELECT * FROM atestv4; ***(press return to proceed or enter x and return to cancel)******************** one | two | three -----+-----+------- (0 rows) ***(Single step mode: verify command)******************************************* SELECT * FROM atest2; ***(press return to proceed or enter x and return to cancel)******************** col1 | col2 ------+------ bar | bar | t (2 rows) ***(Single step mode: verify command)******************************************* SELECT * FROM atestv2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:143: ERROR: permission denied for relation atest2 You are now connected to database "regression". ***(Single step mode: verify command)******************************************* REVOKE ALL PRIVILEGES ON LANGUAGE sql FROM PUBLIC; ***(press return to proceed or enter x and return to cancel)******************** REVOKE ***(Single step mode: verify command)******************************************* GRANT USAGE ON LANGUAGE sql TO regressuser1; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* GRANT USAGE ON LANGUAGE c TO PUBLIC; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:153: ERROR: language "c" is not trusted ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser1; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* GRANT USAGE ON LANGUAGE sql TO regressuser2; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:156: ERROR: permission denied for language sql ***(Single step mode: verify command)******************************************* CREATE FUNCTION testfunc1(int) RETURNS int AS 'select 2 * $1;' LANGUAGE sql; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:157: ERROR: function "testfunc1" already exists with same argument types ***(Single step mode: verify command)******************************************* CREATE FUNCTION testfunc2(int) RETURNS int AS 'select 3 * $1;' LANGUAGE sql; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:158: ERROR: function "testfunc2" already exists with same argument types ***(Single step mode: verify command)******************************************* REVOKE ALL ON FUNCTION testfunc1(int), testfunc2(int) FROM PUBLIC; ***(press return to proceed or enter x and return to cancel)******************** REVOKE ***(Single step mode: verify command)******************************************* GRANT EXECUTE ON FUNCTION testfunc1(int), testfunc2(int) TO regressuser2; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* GRANT USAGE ON FUNCTION testfunc1(int) TO regressuser3; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:162: ERROR: invalid privilege type USAGE for function ***(Single step mode: verify command)******************************************* GRANT ALL PRIVILEGES ON FUNCTION testfunc1(int) TO regressuser4; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* GRANT ALL PRIVILEGES ON FUNCTION testfunc_nosuch(int) TO regressuser4; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:164: ERROR: function testfunc_nosuch(integer) does not exist ***(Single step mode: verify command)******************************************* CREATE FUNCTION testfunc4(boolean) RETURNS text AS 'select col1 from atest2 where col2 = $1;' LANGUAGE sql SECURITY DEFINER; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:168: ERROR: function "testfunc4" already exists with same argument types ***(Single step mode: verify command)******************************************* GRANT EXECUTE ON FUNCTION testfunc4(boolean) TO regressuser3; ***(press return to proceed or enter x and return to cancel)******************** GRANT ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser2; ***(press return to proceed or enter x and return to cancel)******************** SET ***(Single step mode: verify command)******************************************* SELECT testfunc1(5), testfunc2(5); ***(press return to proceed or enter x and return to cancel)******************** testfunc1 | testfunc2 -----------+----------- 10 | 15 (1 row) ***(Single step mode: verify command)******************************************* CREATE FUNCTION testfunc3(int) RETURNS int AS 'select 2 * $1;' LANGUAGE sql; ***(press return to proceed or enter x and return to cancel)******************** psql:privileges.sql:173: ERROR: function "testfunc3" already exists with same argument types ***(Single step mode: verify command)******************************************* SET SESSION AUTHORIZATION regressuser3; ***(press return to proceed or enter x and return to cancel)******************** x ***(Single step mode: verify command)******************************************* SELECT testfunc1(5); ***(press return to proceed or enter x and return to cancel)******************** regression=> select? ?? ?? ?? ?? ?? ????\?~d? ?? ?d? ?c regression ler You are now connected to database "regression" as user "ler". regression=# select * from pg_language; ***(Single step mode: verify command)******************************************* select * from pg_language; ***(press return to proceed or enter x and return to cancel)******************** lanname | lanispl | lanpltrusted | lanplcallfoid | lanvalidator | lanacl ----------+---------+--------------+---------------+--------------+-------- -------------------------- internal | f | f | 0 | 2246 | c | f | f | 0 | 2247 | plpgsql | t | t | 2218642 | 0 | sql | f | t | 0 | 2248 | {=U/postgres,regressuser1=U/ler} (4 rows) regression=# select * from pg_shadow; ***(Single step mode: verify command)******************************************* select * from pg_shadow; ***(press return to proceed or enter x and return to cancel)******************** usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig --------------+----------+-------------+----------+-----------+------------ -------------------------+----------+----------- horde | 407 | t | f | f | md5789761213b76339cb1da715d0c51d888 | | ler | 101 | t | t | t | md5dc936a84fbec3cdca4209c15f1ce424d | | mrm | 401 | t | f | f | md59a6f9a2291c2b99dfa7794167f6f90e5 | | cph | 151 | t | f | f | md56f213a50183cb0b5b503391c96061751 | | nobody | 403 | f | f | f | md5eaa50fc990ef9147accb04fd39c69263 | | ed | 402 | t | f | f | md56d10f55bec241097be543d50441902a4 | | webmail | 404 | t | f | f | md5939853e11c511400d5709c547287a8a9 | | tipnet | 405 | t | f | f | md5ceba6024d54ca3d68647dae1cd58222a | | nagios | 408 | f | f | f | md5d36bbc9979deee7cca850e582b9a8e18 | | webcal | 409 | f | f | f | md5e736e686ce964baaa81ec18583f06921 | | bric | 413 | f | f | f | md55a71606fd33d3e92229ce73ad6c3f408 | | ohp | 410 | t | f | f | md59276c229c3c21fdc944a7532db499a01 | | root | 411 | t | t | t | md5a54504778e2f7c06d13e420bca278b16 | | rt_user | 412 | f | f | f | md5e5ffbd5626278386cfa50d801ce24517 | | regressuser1 | 414 | f | f | f | | | postgres | 1 | t | t | t | md51a4c61baf99fb9be1b8763c70f4304e7 | | regressuser2 | 415 | f | f | f | | | regressuser3 | 416 | f | f | f | | | regressuser4 | 417 | f | f | f | | | (19 rows) regression=# select *? ?current_user session_user;???????????????[1@, ***(Single step mode: verify command)******************************************* select current_user, session_user; ***(press return to proceed or enter x and return to cancel)******************** current_user | session_user --------------+-------------- ler | ler (1 row) regression=# \q $ script done on Sat Oct 25 16:36:56 2003 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -
Re: Call for port reports
Johan Henselmans <johan@netsense.nl> — 2003-10-25T21:52:14Z
On 24-okt-03, at 17:37, Bruce Momjian wrote: > It is time for people to report their port testing. Please test > against > current CVS or beta5 and report your 'uname -a'. > > The current list is at: > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported- > platforms.html > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (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 > majordomo@postgresql.org) > I had trouble compiling postgressrc/pgsql/src/interfaces/ecpg/ecpglib and compiling pgsql/src/interfaces/ecpg/compatlib. Reason was I had asked during configure to include krb5 support. After adding the -lkrb5 flag to the Makefile in these subdirectories, everyting went fine. My configure options: export JAVA_HOME=/usr export PATH=/usr/local/bin:$PATH:/Developer/Java/J2EE/apache-ant-1.5.3/bin ./configure --bindir=/usr/local/bin --mandir=/usr/local/share/man/ --enable-recode --enable-odbc --enable-syslog --enable-unicode-conversion --enable-multibyte --with-CXX --enable-python --with-java --with-krb5=/usr --with-rendezvous --with-openssl=/usr/include/openssl uname -a: Darwin albatros.nest.nl 7.0.0 Darwin Kernel Version 7.0.0: Wed Sep 24 15:48:39 PDT 2003; root:xnu/xnu-517.obj~1/RELEASE_PPC Power Macintosh powerpc -johan Johan Henselmans http://www.netsense.nl Tel: +31-20-6267538 Fax: +31-20-6273852
-
Re: Call for port reports
Kevin Brown <kevin@sysexperts.com> — 2003-10-25T22:26:45Z
Bruce Momjian wrote: > How does everyone like this patch? It removes -g from non-debug > compiles, and changes -O2 to -O for FreeBSD/Alpha. I'd be hesitant to remove -g from non-debug compiles. If something crashes, it's useful to be able to get a good stacktrace from the resulting core file. The -g option makes that possible for optimized code when compiling with gcc. Is there any way we can have configure put -g in when it detects gcc? -- Kevin Brown kevin@sysexperts.com
-
Re: Call for port reports
Andrew Dunstan <andrew@dunslane.net> — 2003-10-25T22:40:06Z
Peter Eisentraut wrote: >Kurt Roeckx writes: > > > >>configure: using CFLAGS=-g -O2 -fno-strict-aliasing >>checking whether the C compiler still works... no >>configure: error: cannot proceed >>oink% gcc -v >>Reading specs from >>/usr/local/lib/gcc-lib/i386-pc-solaris2.6/2.8.1/specs >>gcc version 2.8.1 >> >>CFLAGS="-g -O2" ./configure --without-readline >> >> > >I've installed a detection logic that finds out whether >-fno-strict-aliasing works. Please give it a quick run through, then we >check this platform off. > > I thought we'd have to do this in the end, although that is quite an old version of gcc! cheers andrew
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T00:01:03Z
After CVS update for optimization flags: Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > This one is OK: > > FreeBSD 4.8-RELEASE alpha > > BUT: The default CFLAGS are set by configure to -O2, although the template > wants -O. I manually modified the CFLAGS to -O after configure. > > -- > Peter Eisentraut peter_e@gmx.net > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T00:01:56Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > This one is OK after the recent pthread.h patch: > > NetBSD 1.6 (GENERIC) i386 > > However, the compile pointed out that in src/interfaces/libpq/fe-auth.c > line 472, variable "cmsg" is unused; and indeed it seems to be right. > Bruce, you worked most often on the peer authentication code, so maybe you > can check that. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T00:32:10Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html Again, I need help converting this name to SGML. --------------------------------------------------------------------------- Hans-Jrgen Schnig wrote: > Regression testing on AIX 5 using 7.4beta5: > > > polymorphism ... ok > stats ... ok > ============== shutting down postmaster ============== > > ====================== > All 93 tests passed. > ====================== > > > bash-2.05$ uname -a > AIX sn2 1 5 0044276A4C00 > > > checking build system type... powerpc-ibm-aix5.1.0.0 > checking host system type... powerpc-ibm-aix5.1.0.0 > checking which template to use... aix > > bash-2.05$ gcc -v > Reading specs from > /usr/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix43-010414/specs > gcc version 2.9-aix43-010414 > > Good work :) > > Hans > > -- > Cybertec Geschwinde u Schoenig > Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria > Tel: +43/2952/30706 or +43/660/816 40 77 > www.cybertec.at, www.postgresql.at, kernel.cybertec.at > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T00:42:36Z
I am confused by your report. I have success from Solaris kernel 5.8. I see 2.6 mentioned, and I know there is Solaris 7-9. What does uname -a show? --------------------------------------------------------------------------- Kurt Roeckx wrote: > On Fri, Oct 24, 2003 at 11:37:32AM -0400, Bruce Momjian wrote: > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > checking build system type... i386-pc-solaris2.6 > checking host system type... i386-pc-solaris2.6 > checking which template to use... solaris > [...] > checking for gcc... gcc > checking for C compiler default output... a.out > checking whether the C compiler works... yes > [...] > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > configure: using CFLAGS=-g -O2 -fno-strict-aliasing > checking whether the C compiler still works... no > configure: error: cannot proceed > oink% gcc -v > Reading specs from > /usr/local/lib/gcc-lib/i386-pc-solaris2.6/2.8.1/specs > gcc version 2.8.1 > > CFLAGS="-g -O2" ./configure --without-readline > [...] > ====================== > All 93 tests passed. > ====================== > > > Kurt > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T00:45:48Z
Peter Eisentraut wrote: > Bruce Momjian writes: > > > In fact, another question is why this alpha test is only done in > > freebsd? > > Ask that to the maintainers of the FreeBSD system compiler. > > > Certainly other alpha gcc platforms must have problems with -O2? > > I am inclined to add something to configure.in for all alpha compiles > > that changes -O2 to -O. > > I'm not. It's one thing if FreeBSD thinks their compiler is broken. But > before I accept that gcc is broken as a whole, I want to hear from the GCC > folks. We might get more gcc -O2 alpha warning reports now that we use -O2 by default --- let's see. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T01:04:44Z
Peter Eisentraut wrote: > Peter Eisentraut writes: > > > FreeBSD 4.8-RELEASE alpha > > > > BUT: The default CFLAGS are set by configure to -O2, although the template > > wants -O. I manually modified the CFLAGS to -O after configure. > > I've committed a fix for the CFLAGS handling, and now this platform works > perfectly. Your approach looks good. You decided to allow template to set the CFLAGS, and if it doesn't, make it -O2/-O. That is a very clean approach. I had the idea of layering the flags so template would only _add_ to CFLAGS, but your way is clearer. One other idea would be to set CFLAGS to "" before including template, and just test to see if it is still "" after --- that might be cleaner than saving the original value and comparing. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T01:06:47Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > After the just-committed fix, Tru64 5.1 alpha is OK with both cc and gcc. > > -- > Peter Eisentraut peter_e@gmx.net > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T01:29:56Z
Kevin Brown wrote: > Bruce Momjian wrote: > > How does everyone like this patch? It removes -g from non-debug > > compiles, and changes -O2 to -O for FreeBSD/Alpha. > > I'd be hesitant to remove -g from non-debug compiles. If something > crashes, it's useful to be able to get a good stacktrace from the > resulting core file. The -g option makes that possible for optimized > code when compiling with gcc. > > Is there any way we can have configure put -g in when it detects gcc? Even without -g, you still get function names in the backtrace. The only time you don't get this is when you strip the executable. -g adds the function line number. configure --enable-debug will use -g for the compile, and with optimization. We aren't changing that, we are only preventing -g by default. Most installers are stripping the executables anyway --- this might discourage them from doing that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T01:48:19Z
Impressive. We already have a long list of supported 7.4 platforms, all in 24 hours! http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2003-10-26T08:17:28Z
I should mention that I don't have access to a FreeBSD Alpha box anymore :( Hence, I have no idea if it currently compiles or not. Chris Peter Eisentraut wrote: > Bruce Momjian writes: > > >>It is time for people to report their port testing. Please test against >>current CVS or beta5 and report your 'uname -a'. > > > FreeBSD svr1.postgresql.org 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #4: Sat Sep 20 14:41:58 ADT 2003 i386 >
-
Re: Call for port reports
Kurt Roeckx <q@ping.be> — 2003-10-26T10:41:56Z
On Sat, Oct 25, 2003 at 08:42:36PM -0400, Bruce Momjian wrote: > > I am confused by your report. I have success from Solaris kernel 5.8. > I see 2.6 mentioned, and I know there is Solaris 7-9. What does uname > -a show? SunOS oink 5.6 Generic_105182-09 i86pc i386 i86pc Which is the same as Solaris 2.6. Kurt
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T13:24:13Z
Christopher Kings-Lynne wrote: > I should mention that I don't have access to a FreeBSD Alpha box anymore > :( Hence, I have no idea if it currently compiles or not. > No problem --- Peter go it. > Chris > > > Peter Eisentraut wrote: > > > Bruce Momjian writes: > > > > > >>It is time for people to report their port testing. Please test against > >>current CVS or beta5 and report your 'uname -a'. > > > > > > FreeBSD svr1.postgresql.org 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #4: Sat Sep 20 14:41:58 ADT 2003 i386 > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T13:27:10Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html Should I mention Solaris as 2.6 or 5.6? --------------------------------------------------------------------------- Kurt Roeckx wrote: > On Sat, Oct 25, 2003 at 08:42:36PM -0400, Bruce Momjian wrote: > > > > I am confused by your report. I have success from Solaris kernel 5.8. > > I see 2.6 mentioned, and I know there is Solaris 7-9. What does uname > > -a show? > > SunOS oink 5.6 Generic_105182-09 i86pc i386 i86pc > > Which is the same as Solaris 2.6. > > > Kurt > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Kurt Roeckx <q@ping.be> — 2003-10-26T14:14:59Z
On Sun, Oct 26, 2003 at 08:27:10AM -0500, Bruce Momjian wrote: > > Ports list updated: > > http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html > > Should I mention Solaris as 2.6 or 5.6? Normally you speak about Solaris 2.5, 2.6, 7, 8 and 9. Which are also known as SunOS 5.5, 5.6, 5.7, 5.8 and 5.9. Either number will probably. PS: My 2.6/5.6 was on x86 hardware, not on a sparc. Kurt
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-26T14:31:19Z
Kurt Roeckx wrote: > On Sun, Oct 26, 2003 at 08:27:10AM -0500, Bruce Momjian wrote: > > > > Ports list updated: > > > > http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html > > > > Should I mention Solaris as 2.6 or 5.6? > > Normally you speak about Solaris 2.5, 2.6, 7, 8 and 9. > Which are also known as SunOS 5.5, 5.6, 5.7, 5.8 and 5.9. > > Either number will probably. > > > PS: My 2.6/5.6 was on x86 hardware, not on a sparc. Oh! Thanks. Updated. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports / test horology FAILED
Tilo Schwarz <mail@tilo-schwarz.de> — 2003-10-26T22:06:53Z
Hi together, keep on the nice work! On SuSE 8.0, > uname -a Linux dell 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown During compile I got the following warning: gcc -g -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -D_GNU_SOURCE -c trigger.c -o trigger.o /tmp/ccgcppC9.s: Assembler messages: /tmp/ccgcppC9.s:2014: Warning: using `%si' instead of `%esi' due to `w' suffix /tmp/ccgcppC9.s:2014: Warning: using `%ax' instead of `%eax' due to `w' suffix > as -v GNU assembler version 2.11.92.0.10 (i486-suse-linux) using BFD version 2.11.92.0.10 20011021 (SuSE) > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs gcc version 2.95.3 20010315 (SuSE) I get the this failure (...something to do with the change to winter time last night?): test horology ... FAILED, diff follows. Bye, Tilo > cat src/test/regress/regression.diffs *** ./expected/horology.out Thu Sep 25 08:58:06 2003 --- ./results/horology.out Sun Oct 26 22:54:56 2003 *************** *** 583,595 **** SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - interval '1 day')) as "True"; True ------ ! t (1 row) SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 'yesterday' + interval '2 days')) as "True"; True ------ ! t (1 row) SELECT (timestamp with time zone 'tomorrow' > 'now') as "True"; --- 583,595 ---- SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - interval '1 day')) as "True"; True ------ ! f (1 row) SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 'yesterday' + interval '2 days')) as "True"; True ------ ! f (1 row) SELECT (timestamp with time zone 'tomorrow' > 'now') as "True"; *************** *** 836,842 **** + interval '02:01' AS time with time zone) AS time) AS "03:31:00"; 03:31:00 ---------- ! 03:31:00 (1 row) SELECT CAST(cast(date 'today' + time with time zone '03:30' --- 836,842 ---- + interval '02:01' AS time with time zone) AS time) AS "03:31:00"; 03:31:00 ---------- ! 02:31:00 (1 row) SELECT CAST(cast(date 'today' + time with time zone '03:30' ====================================================================== *** ./expected/random.out Thu Feb 13 06:24:04 2003 --- ./results/random.out Sun Oct 26 22:55:01 2003 *************** *** 25,31 **** GROUP BY random HAVING count(random) > 1; random | count --------+------- ! (0 rows) SELECT random FROM RANDOM_TBL WHERE random NOT BETWEEN 80 AND 120; --- 25,32 ---- GROUP BY random HAVING count(random) > 1; random | count --------+------- ! 113 | 2 ! (1 row) SELECT random FROM RANDOM_TBL WHERE random NOT BETWEEN 80 AND 120; ====================================================================== -
Re: Call for port reports / test horology FAILED
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-27T02:55:13Z
Tilo Schwarz wrote: > Hi together, keep on the nice work! > > On SuSE 8.0, > > uname -a > Linux dell 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown > > During compile I got the following warning: > gcc -g -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes > -Wmissing-declarations -I../../../src/include -D_GNU_SOURCE -c trigger.c -o > trigger.o > /tmp/ccgcppC9.s: Assembler messages: > /tmp/ccgcppC9.s:2014: Warning: using `%si' instead of `%esi' due to `w' suffix > /tmp/ccgcppC9.s:2014: Warning: using `%ax' instead of `%eax' due to `w' suffix > > > as -v > GNU assembler version 2.11.92.0.10 (i486-suse-linux) using BFD version > 2.11.92.0.10 20011021 (SuSE) > > gcc -v > Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs > gcc version 2.95.3 20010315 (SuSE) Yes, I see that with the exact same version of gcc, but it seems to still run fine. > I get the this failure (...something to do with the change to winter time last > night?): > > test horology ... FAILED, diff follows. > Yes, this is caused by the daylight savings time change --- it will be OK tomorrow. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Neil Conway <neilc@samurai.com> — 2003-10-27T09:57:30Z
On Sat, 2003-10-25 at 21:29, Bruce Momjian wrote: > configure --enable-debug will use -g for the compile, and with > optimization. I'm just curious: would there be any benefit to using -g3 when --enable-debug is specified and -g3 is supported by gcc? From the gcc man page: -glevel [...] Request debugging information and also use level to specify how much information. The default level is 2. Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug. This includes descriptions of functions and external variables, but no information about local variables and no line numbers. Level 3 includes extra information, such as all the macro defini- tions present in the program. Some debuggers support macro expan- sion when you use -g3. Note that in order to avoid confusion between DWARF1 debug level 2, and DWARF2, neither -gdwarf nor -gdwarf-2 accept a concatenated debug level. Instead use an additional -glevel option to change the debug level for DWARF1 or DWARF2. -Neil
-
Re: Call for port reports
Tom Lane <tgl@sss.pgh.pa.us> — 2003-10-29T00:39:54Z
Johan Henselmans <johan@netsense.nl> writes: > I had trouble compiling postgressrc/pgsql/src/interfaces/ecpg/ecpglib > and compiling pgsql/src/interfaces/ecpg/compatlib. > Reason was I had asked during configure to include krb5 support. After > adding the -lkrb5 flag to the Makefile in these subdirectories, > everyting went fine. Okay, fixed. regards, tom lane
-
Re: Call for port reports
Sean Chittenden <sean@chittenden.org> — 2003-10-29T01:13:27Z
> > Certainly other alpha gcc platforms must have problems with -O2? > > I am inclined to add something to configure.in for all alpha > > compiles that changes -O2 to -O. > > I'm not. It's one thing if FreeBSD thinks their compiler is broken. > But before I accept that gcc is broken as a whole, I want to hear > from the GCC folks. Well, I have no insite into the gcc camp, but, my understanding is that gcc 3.3 for the alpha isn't broken, but for gcc 2.X, it's pretty horked with any level of optimization. -sc -- Sean Chittenden
-
Re: Call for port reports
alessio@albourne.com — 2003-10-29T11:45:42Z
On Fri, 2003-10-24 at 18:37, Bruce Momjian wrote: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. Sorry for the delay. All regression tests passed on Alpha Tru64/ Digital Unix version 4.0g using Digital CC. OSF1 emily V4.0 1530 alpha (the existing port list has only a report for Tru64 5.X) -- Alessio Bragadini <alessio@albourne.com> APL Financial Services (Overseas) Ltd
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-29T13:42:59Z
Ports list updated: http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Alessio Bragadini wrote: > On Fri, 2003-10-24 at 18:37, Bruce Momjian wrote: > > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > Sorry for the delay. All regression tests passed on Alpha Tru64/ > Digital Unix version 4.0g using Digital CC. > > OSF1 emily V4.0 1530 alpha > > (the existing port list has only a report for Tru64 5.X) > > -- > Alessio Bragadini <alessio@albourne.com> > APL Financial Services (Overseas) Ltd > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Tom Lane <tgl@sss.pgh.pa.us> — 2003-10-31T05:01:53Z
Bruce Momjian <pgman@candle.pha.pa.us> writes: > One other idea would be to set CFLAGS to "" before including template, > and just test to see if it is still "" after --- that might be cleaner > than saving the original value and comparing. Yeah, that bothered me a bit too --- what if the template tries to set CFLAGS to its already-existing value? I was thinking that unsetting CFLAGS before running the template would be the best answer. regards, tom lane
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-31T10:40:25Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. For a change, here is one that does not work: HP-UX hpunix5 B.11.00 U 9000/803 2002765023 Using the system compiler, I get several complaints about our use of "inline", for example: cc -Ae +O2 -I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -c -o dynahash.o dynahash.c cc: "dynahash.c", line 466: error 1000: Unexpected symbol: "calc_bucket". cc: panic 2017: Cannot recover from earlier errors, terminating. I had to patch it as follows to get it to work: diff -ur ../cvs-pgsql/src/backend/utils/hash/dynahash.c ./src/backend/utils/hash/dynahash.c --- ../cvs-pgsql/src/backend/utils/hash/dynahash.c 2003-08-19 03:13:41.000000000 +0200 +++ ./src/backend/utils/hash/dynahash.c 2003-10-31 11:05:05.000000000 +0100 @@ -462,7 +462,7 @@ /* Convert a hash value to a bucket number */ -static inline uint32 +static uint32 calc_bucket(HASHHDR *hctl, uint32 hash_val) { uint32 bucket; diff -ur ../cvs-pgsql/src/backend/utils/sort/tuplesort.c ./src/backend/utils/sort/tuplesort.c --- ../cvs-pgsql/src/backend/utils/sort/tuplesort.c 2003-08-17 21:58:06.000000000 +0200 +++ ./src/backend/utils/sort/tuplesort.c 2003-10-31 11:10:12.000000000 +0100 @@ -1784,7 +1784,7 @@ /* * Inline-able copy of FunctionCall2() to save some cycles in sorting. */ -static inline Datum +static Datum myFunctionCall2(FmgrInfo *flinfo, Datum arg1, Datum arg2) { FunctionCallInfoData fcinfo; @@ -1816,7 +1816,7 @@ * and return a 3-way comparison result. This takes care of handling * NULLs and sort ordering direction properly. */ -static inline int32 +static int32 inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, Datum datum1, bool isNull1, Datum datum2, bool isNull2) Any ideas? -- Peter Eisentraut peter_e@gmx.net -
Re: Call for port reports
Tom Lane <tgl@sss.pgh.pa.us> — 2003-10-31T15:57:55Z
Peter Eisentraut <peter_e@gmx.net> writes: > HP-UX hpunix5 B.11.00 U 9000/803 2002765023 > Using the system compiler, I get several complaints about our use of > "inline", for example: Interesting. CVS tip works fine for me on HPUX 10.20, using cc -Ae. It looks like configure deduces inline is not supported on this compiler, though: /* Define as `__inline' if that's what the C compiler calls it, or to nothing if it is not supported. */ #define inline What do you get on that compiler? > I had to patch it as follows to get it to work: Odd. I count ten inline functions in the backend: src/backend/storage/lmgr/lock.c: 94: inline static bool src/backend/storage/lmgr/lock.c: 105: inline static void src/backend/storage/lmgr/lock.c: 126: inline static void src/backend/storage/lmgr/lwlock.c: 67: inline static void src/backend/storage/lmgr/lwlock.c: 77: inline static void src/backend/utils/adt/pg_lzcompress.c: 389: static inline int src/backend/utils/hash/dynahash.c: 465: static inline uint32 src/backend/utils/mmgr/aset.c: 256: static inline int src/backend/utils/sort/tuplesort.c: 1787: static inline Datum src/backend/utils/sort/tuplesort.c: 1819: static inline int32 Why would only three of them fail? I'm not eager to remove the inlining optimization for everyone just because this one compiler fails. I think a more reasonable approach would be to force inline to be #define'd as empty on that platform. Or file a bug report with HP. regards, tom lane
-
Re: Call for port reports
Tom Lane <tgl@sss.pgh.pa.us> — 2003-10-31T16:09:09Z
Bruce Momjian <pgman@candle.pha.pa.us> writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. I can confirm CVS tip on HPUX 10.20, using both gcc and vendor's cc. $ uname -a HP-UX sss2 B.10.20 C 9000/780 2004473515 32-user license Looks like there are already confirmations for the other platforms I have at hand ... regards, tom lane
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-31T16:20:57Z
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > One other idea would be to set CFLAGS to "" before including template, > > and just test to see if it is still "" after --- that might be cleaner > > than saving the original value and comparing. > > Yeah, that bothered me a bit too --- what if the template tries to set > CFLAGS to its already-existing value? I was thinking that unsetting > CFLAGS before running the template would be the best answer. I assume he did it that way so if you do: CFLAGS= in the template file that it would be honored. I see lots of this in configure: ac_env_CFLAGS_set=${CFLAGS+set} but that uses 'set' if the variable is null or unset: ${parameter:+word} Use Alternate Value. If parameter is null or unset, nothing is substituted, otherwise the expan- sion of word is substituted. However, I thought null meant "", but I now think null basically means the same as unset in this manual page. Notice that '+' tests only for unset, and knows when you have done VAR= and VAR="": $ echo ${Y+no} $ Y= $ echo ${Y+no} no $ Y="" $ echo ${Y+no} no $ unset Y $ echo ${Y+no} $ so the proper test would be to unset the variable, then use ${var+val} to test CFLAGS after the template file is included. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 -
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-10-31T16:37:10Z
Tom Lane writes: > Odd. I count ten inline functions in the backend: > Why would only three of them fail? I just remembered this Autoconf change: 2002-03-28 Kevin Ryde <user42@zip.com.au> * lib/autoconf/c.m4 (AC_C_INLINE): Test with a typedef return value, to avoid versions of HP C which don't allow that. So there you have it. Do we want to backpatch the new autoconf test, or define inline to empty for this particular version of this platform, or try to do without typedef'd types? I prefer option 1. -- Peter Eisentraut peter_e@gmx.net -
Re: Call for port reports
Tom Lane <tgl@sss.pgh.pa.us> — 2003-10-31T17:02:57Z
Peter Eisentraut <peter_e@gmx.net> writes: > * lib/autoconf/c.m4 (AC_C_INLINE): Test with a typedef return value, > to avoid versions of HP C which don't allow that. > So there you have it. Do we want to backpatch the new autoconf test, or > define inline to empty for this particular version of this platform, or > try to do without typedef'd types? I prefer option 1. Me too, if the patch isn't too big. regards, tom lane
-
Re: Call for port reports -- Failure on Linux
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-31T21:25:41Z
Did we ever find the cause of this failure? --------------------------------------------------------------------------- Rod Taylor wrote: -- Start of PGP signed section. > Linux ns2 2.4.20-xfs #2 Tue Apr 15 10:04:43 EDT 2003 i686 unknown > > <-- SNIP --> > stats ... FAILED > ============== shutting down postmaster ============== > > ======================= > 1 of 93 tests failed. > ======================= > > > *** ./expected/stats.out Sat Sep 13 12:44:48 2003 > --- ./results/stats.out Fri Oct 24 14:26:56 2003 > *************** > *** 8,14 **** > SHOW stats_start_collector; -- must be on > stats_start_collector > ----------------------- > ! on > (1 row) > > -- save counters > --- 8,14 ---- > SHOW stats_start_collector; -- must be on > stats_start_collector > ----------------------- > ! off > (1 row) > > -- save counters > *************** > *** 62,68 **** > WHERE st.relname='tenk2' AND cl.relname='tenk2'; > ?column? | ?column? | ?column? | ?column? > ----------+----------+----------+---------- > ! t | t | t | t > (1 row) > > SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + > cl.relpages, > --- 62,68 ---- > WHERE st.relname='tenk2' AND cl.relname='tenk2'; > ?column? | ?column? | ?column? | ?column? > ----------+----------+----------+---------- > ! f | f | f | f > (1 row) > > SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + > cl.relpages, > *************** > *** 71,77 **** > WHERE st.relname='tenk2' AND cl.relname='tenk2'; > ?column? | ?column? > ----------+---------- > ! t | t > (1 row) > > -- clean up > --- 71,77 ---- > WHERE st.relname='tenk2' AND cl.relname='tenk2'; > ?column? | ?column? > ----------+---------- > ! f | f > (1 row) > > -- clean up > > > > > On Fri, 2003-10-24 at 11:37, Bruce Momjian wrote: > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > > > The current list is at: > > > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html -- End of PGP section, PGP failed! -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-11-01T03:36:11Z
Bruce Momjian writes: > It is time for people to report their port testing. Please test against > current CVS or beta5 and report your 'uname -a'. This one is OK: OpenBSD ob.credativ.de 3.4 GENERIC#65 sparc -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Peter Eisentraut <peter_e@gmx.net> — 2003-11-04T10:09:23Z
I wrote: > For a change, here is one that does not work: > > HP-UX hpunix5 B.11.00 U 9000/803 2002765023 This one is OK now. -- Peter Eisentraut peter_e@gmx.net
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-11-08T23:36:38Z
Kurt, this patch added special includes for testing un.h, and I believe it caused regression failures for the statistics collector. Is it still needed? What platform is this? --------------------------------------------------------------------------- Kurt Roeckx wrote: > On Fri, Oct 24, 2003 at 11:37:32AM -0400, Bruce Momjian wrote: > > It is time for people to report their port testing. Please test against > > current CVS or beta5 and report your 'uname -a'. > > I need this small patch so it properly detects I have unix domain > sockets. Otherwise no problems. > > > Kurt > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Bruce Momjian <pgman@candle.pha.pa.us> — 2003-11-09T02:02:46Z
I just tested gcc 2.95.3 on BSD/OS i386 and didn't see any change when using -g3 vs -g in the size of the binaries. --------------------------------------------------------------------------- Neil Conway wrote: > On Sat, 2003-10-25 at 21:29, Bruce Momjian wrote: > > configure --enable-debug will use -g for the compile, and with > > optimization. > > I'm just curious: would there be any benefit to using -g3 when > --enable-debug is specified and -g3 is supported by gcc? From the gcc > man page: > > -glevel > > [...] > > Request debugging information and also use level to specify how > much information. The default level is 2. > > Level 1 produces minimal information, enough for making backtraces > in parts of the program that you don't plan to debug. This > includes descriptions of functions and external variables, but no > information about local variables and no line numbers. > > Level 3 includes extra information, such as all the macro defini- > tions present in the program. Some debuggers support macro expan- > sion when you use -g3. > > Note that in order to avoid confusion between DWARF1 debug level 2, > and DWARF2, neither -gdwarf nor -gdwarf-2 accept a concatenated > debug level. Instead use an additional -glevel option to change > the debug level for DWARF1 or DWARF2. > > -Neil > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Call for port reports
Kurt Roeckx <q@ping.be> — 2003-11-09T02:24:00Z
On Sat, Nov 08, 2003 at 06:36:38PM -0500, Bruce Momjian wrote: > > Kurt, this patch added special includes for testing un.h, and I believe > it caused regression failures for the statistics collector. Is it still > needed? What platform is this? It's a linux system with an (old) libc5. It's still needed for that platform, but I doubt many people would use it. On what platfrom does it break? Is the result of checking for un.h different? The stats collector has this code that is relevant: for (addr = addrs; addr; addr = addr->ai_next) { #ifdef HAVE_UNIX_SOCKETS /* Ignore AF_UNIX sockets, if any are returned. */ if (addr->ai_family == AF_UNIX) continue; #endif if ((pgStatSock = socket(addr->ai_family, SOCK_DGRAM, 0)) >= 0) break; } Kurt -
Re: Call for port reports
Tom Lane <tgl@sss.pgh.pa.us> — 2003-11-09T04:02:37Z
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I just tested gcc 2.95.3 on BSD/OS i386 and didn't see any change when > using -g3 vs -g in the size of the binaries. I saw the same with gcc 2.95.3 on HPUX. The gcc manual for this version does claim that -g3 dumps extra info, but perhaps that is only true in certain object-file formats. regards, tom lane