Thread: Call for port reports

Call for port reports

From

Bruce Momjian

Date:

24 October 2003, 15:38:55

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,
Pennsylvania19073

Re: Call for port reports

From

Adam Witney

Date:

24 October 2003, 15:50:36

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

From

Bruce Momjian

Date:

24 October 2003, 15:58:11

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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

24 October 2003, 16:24:31

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

From

Peter Eisentraut

Date:

24 October 2003, 16:25:41

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

From

Bruce Momjian

Date:

24 October 2003, 16:29:52

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

24 October 2003, 16:31:34

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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

24 October 2003, 16:42:37

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

From

Peter Eisentraut

Date:

24 October 2003, 18:33:43

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

From

Marko Karppinen

Date:

24 October 2003, 18:40:24

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

From

Marko Karppinen

Date:

24 October 2003, 19:00:37

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

From

Marko Karppinen

Date:

24 October 2003, 19:10:35

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

From

Peter Eisentraut

Date:

24 October 2003, 19:57:57

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

From

Peter Eisentraut

Date:

24 October 2003, 20:28:17

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

From

Rod Taylor

Date:

24 October 2003, 20:37:54

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

From

Bruce Momjian

Date:

24 October 2003, 20:37:56

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

24 October 2003, 20:39:26

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

24 October 2003, 20:45:56

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

24 October 2003, 20:48:58

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

24 October 2003, 20:50:07

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

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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

24 October 2003, 21:07:16

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

From

Bruce Momjian

Date:

24 October 2003, 21:10:51

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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

24 October 2003, 21:44:34

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

From

Bruce Momjian

Date:

24 October 2003, 21:47:06

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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

24 October 2003, 21:59:13

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

From

Robert Treat

Date:

24 October 2003, 22:01:24

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

From

Peter Eisentraut

Date:

24 October 2003, 22:04:44

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

From

Christopher Browne

Date:

24 October 2003, 22:15:03

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

From

Kurt Roeckx

Date:

24 October 2003, 22:25:22

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

sys_un_h.diff

Re: Call for port reports

From

Christopher Browne

Date:

24 October 2003, 22:45:03

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:
syntaxerror 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

From

Peter Eisentraut

Date:

24 October 2003, 22:47:08

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

From

Alvaro Herrera

Date:

24 October 2003, 22:57:16

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

From

Noèl Köthe

Date:

24 October 2003, 23:17:51

> 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

here are some build reports. Its all on Debian GNU/Linux with different
architectures:

======================All 93 tests passed.
======================
rm regress.o
make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/pgsql/src/test'
noel@bruckner:~/pgsql$ uname -a
Linux bruckner 2.4.21 #1 Don Aug 28 15:18:52 CEST 2003 ppc GNU/Linux

---------------------------------------------------------------------

In file included from ../../../../src/include/storage/spin.h:50,                from xlog.c:37:
../../../../src/include/storage/s_lock.h:543:2: #error This platform does not support native spinlocks. To continue the
compile,rerun configure using --disable-spinlocks. However, performance will be poor. Please report this to
pgsql-bugs@postgresql.org.
make[4]: *** [xlog.o] Error 1
make[4]: Leaving directory `/home/noel/pgsql/src/backend/access/transam'
make[3]: *** [transam-recursive] Error 2
make[3]: Leaving directory `/home/noel/pgsql/src/backend/access'
make[2]: *** [access-recursive] Error 2
make[2]: Leaving directory `/home/noel/pgsql/src/backend'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/noel/pgsql/src'
make: *** [all] Error 2
noel@paer:~/pgsql$ uname -a
Linux paer 2.4.20-64 #1 Fri Aug 1 23:40:10 UTC 2003 parisc64 GNU/Linux

rebuild with --disable-spinlocks

...    transactions         ... ok    random               ... failed (ignored)    portals              ... ok
...
==================================================92 of 93 tests passed, 1 failed test(s) ignored.
==================================================
The differences that caused some tests to fail can be viewed in the
file `./regression.diffs'.  A copy of the test summary that you see
above is saved in the file `./regression.out'.
rm regress.o
make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/pgsql/src/test'
noel@paer:~/pgsql$ uname -a
Linux paer 2.4.20-64 #1 Fri Aug 1 23:40:10 UTC 2003 parisc64 GNU/Linux

this is regression.diffs:

*** ./expected/random.out       Thu Feb 13 05:24:04 2003
--- ./results/random.out        Fri Oct 24 22:19:29 2003
***************
*** 31,35 ****   WHERE random NOT BETWEEN 80 AND 120;  random --------
! (0 rows)
--- 31,36 ----   WHERE random NOT BETWEEN 80 AND 120;  random --------
!     122
! (1 row)


-----------------------------------------------------------------------

======================All 93 tests passed.
======================
rm regress.o
make[2]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test'
(sid)noel@debussy:~/postgresql-cvs/pgsql$ uname -a
Linux debussy 2.4.19-netwinder #1 Thu Mar 20 03:14:34 CET 2003 armv4l GNU/Linux

--------------------------------------------------------------------------

======================All 93 tests passed.
======================
rm regress.o
make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/pgsql/src/test'
noel@merulo:~/pgsql$ uname -a
Linux merulo 2.4.18-itanium-smp #1 SMP Sat Nov 23 01:39:07 MST 2002 ia64 GNU/Linux

----------------------------------------------------------------------------

...    transactions         ... ok    random               ... failed (ignored)    portals              ... ok
...
==================================================92 of 93 tests passed, 1 failed test(s) ignored.
==================================================
The differences that caused some tests to fail can be viewed in the
file `./regression.diffs'.  A copy of the test summary that you see
above is saved in the file `./regression.out'.
rm regress.o
make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/pgsql/src/test'
(unstable)noel@raptor:~/pgsql$ uname -a
Linux raptor 2.4.19 #1 SMP Fri Nov 29 23:53:27 CET 2002 s390 GNU/Linux

------------------------------------------------------------------------------

reports of these slower systems will follow but they need a bit more time:

Linux casals 2.4.19-r4k-ip22 #1 Tue Mar 18 15:38:10 CET 2003 mips unknown
Linux crest 2.4.20 #1 Wed Mar 5 01:39:17 EST 2003 m68k unknown
Linux escher 2.4.22 #2 Sat Sep 6 18:23:54 CEST 2003 alpha GNU/Linux

--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org

Re: Call for port reports

From

Peter Eisentraut

Date:

24 October 2003, 23:20:42

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

From

Kurt Roeckx

Date:

24 October 2003, 23:25:58

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

From

Noèl Köthe

Date:

24 October 2003, 23:38:25

Am Sa, den 25.10.2003 schrieb Noèl Köthe um 01:17:

> reports of these slower systems will follow but they need a bit more time:
>
> Linux casals 2.4.19-r4k-ip22 #1 Tue Mar 18 15:38:10 CET 2003 mips unknown
    polymorphism         ... ok    stats                ... ok
============== shutting down postmaster               ==============
======================All 93 tests passed.
======================
rm regress.o
make[2]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test'
noel@casals:~/postgresql-cvs/pgsql$ uname -a
Linux casals 2.4.19-r4k-ip22 #1 Tue Mar 18 15:38:10 CET 2003 mips GNU/Linux

> Linux crest 2.4.20 #1 Wed Mar 5 01:39:17 EST 2003 m68k unknown

gcc -g -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include
-D_GNU_SOURCE  -c -o xlog.o xlog.c 
In file included from ../../../../src/include/storage/spin.h:50,                from xlog.c:37:
../../../../src/include/storage/s_lock.h:543:2: #error This platform does not support native spinlocks. To continue the
compile,rerun configure using --disable-spinlocks. However, performance will be poor. Please report this to
pgsql-bugs@postgresql.org.
make[4]: *** [xlog.o] Error 1
make[4]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/backend/access/transam'

             rebuild is runing with --disable-spinlocks but it needs half of a day. 

--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org

Re: Call for port reports

From

Bruce Momjian

Date:

25 October 2003, 03:18:12

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

25 October 2003, 03:52:11

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
Index: src/backend/libpq/hba.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/libpq/hba.c,v
retrieving revision 1.115
diff -c -c -r1.115 hba.c
*** src/backend/libpq/hba.c    25 Sep 2003 06:57:59 -0000    1.115
--- src/backend/libpq/hba.c    25 Oct 2003 03:38:59 -0000
***************
*** 1433,1447 ****
      struct msghdr msg;

  /* Credentials structure */
! #ifdef HAVE_STRUCT_CMSGCRED
      typedef struct cmsgcred Cred;

  #define cruid cmcred_uid
! #elif HAVE_STRUCT_FCRED
      typedef struct fcred Cred;

  #define cruid fc_uid
! #elif HAVE_STRUCT_SOCKCRED
      typedef struct sockcred Cred;

  #define cruid sc_uid
--- 1433,1447 ----
      struct msghdr msg;

  /* Credentials structure */
! #if defined(HAVE_STRUCT_CMSGCRED)
      typedef struct cmsgcred Cred;

  #define cruid cmcred_uid
! #elif defined(HAVE_STRUCT_FCRED)
      typedef struct fcred Cred;

  #define cruid fc_uid
! #elif defined(HAVE_STRUCT_SOCKCRED)
      typedef struct sockcred Cred;

  #define cruid sc_uid
Index: src/interfaces/libpq/fe-auth.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-auth.c,v
retrieving revision 1.83
diff -c -c -r1.83 fe-auth.c
*** src/interfaces/libpq/fe-auth.c    4 Aug 2003 02:40:16 -0000    1.83
--- src/interfaces/libpq/fe-auth.c    25 Oct 2003 03:39:07 -0000
***************
*** 464,476 ****
      /* Point to start of first structure */
      struct cmsghdr *cmsg = (struct cmsghdr *) cmsgmem;
  #endif
- #ifdef HAVE_STRUCT_SOCKCRED
-     /* Prevent padding */
-     char        cmsgmem[sizeof(struct cmsghdr) + sizeof(struct sockcred)];
-
-     /* Point to start of first structure */
-     struct cmsghdr *cmsg = (struct cmsghdr *) cmsgmem;
- #endif

      /*
       * The backend doesn't care what we send here, but it wants exactly
--- 464,469 ----

Re: Call for port reports

From

"Dave Page"

Date:

25 October 2003, 09:08:05


> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: 24 October 2003 16:38
> To: PostgreSQL-development
> Subject: [HACKERS] Call for port reports
>
> It is time for people to report their port testing.  Please
> test against current CVS or beta5 and report your 'uname -a'.

Cygwin
======

Parallel regression tests do not complete (we normally have problems
with these anyway, though they do normally complete).

Serial tests pass.

CYGWIN_NT-5.1 pc30 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown
Cygwin


Win32 Client
============

(Windows XP Pro, VC++ 6.0)

C:\cygwin\usr\local\src\postgresql-7.4beta5\src>nmake /f win32.mak ALL

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
       cd include       if not exist pg_config.h copy pg_config.h.win32 pg_config.h       cd ..       cd
interfaces\libpq      nmake /f win32.mak 

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

Building the Win32 static library...
       cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nma02744.
getaddrinfo.c
..\..\include\c.h(66) : fatal error C1083: Cannot open include file:
'strings.h'
: No such file or directory
NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' :
return co
de '0x2'
Stop.

Regards, Dave.

Re: Call for port reports

From

Peter Eisentraut

Date:

25 October 2003, 09:19:22

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

From

Noèl Köthe

Date:

25 October 2003, 11:03:51

Am Sa, den 25.10.2003 schrieb Noèl Köthe um 01:17:
> > 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
>
> here are some build reports. Its all on Debian GNU/Linux with different
> architectures:

======================All 93 tests passed.
======================
rm regress.o
make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/pgsql/src/test'
noel@pergolesi:~/pgsql$ uname -a
Linux pergolesi 2.4.22 #1 SMP Mon Aug 25 20:56:25 CEST 2003 i686 GNU/Linux

It says i686 but its AMD Opteron:

noel@pergolesi:~/pgsql$ cat /proc/cpuinfo |more
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 5
model name      : AMD Opteron(tm) Processor 240
stepping        : 1
cpu MHz         : 1394.299
cache size      : 1024 KB
...

--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org

Re: Call for port reports

From

Kurt Roeckx

Date:

25 October 2003, 11:34:08

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

From

Kurt Roeckx

Date:

25 October 2003, 11:48:50

On Sat, Oct 25, 2003 at 01:03:37PM +0200, Noèl Köthe wrote:
> noel@pergolesi:~/pgsql$ uname -a
> Linux pergolesi 2.4.22 #1 SMP Mon Aug 25 20:56:25 CEST 2003 i686 GNU/Linux
> 
> It says i686 but its AMD Opteron:

Just wondering, but does it run in 32 or 64 bit mode?  I have a
feeling it's only 32 bit mode ...  Is it compiled for the i386 or
the x86_64 arch?  Did you have CONFIG_X86_64=y as compile time
option?

Kurt

Re: Call for port reports

From

Noèl Köthe

Date:

25 October 2003, 12:19:07

Am Sa, den 25.10.2003 schrieb Kurt Roeckx um 13:48:

> > Linux pergolesi 2.4.22 #1 SMP Mon Aug 25 20:56:25 CEST 2003 i686 GNU/Linux
> >
> > It says i686 but its AMD Opteron:
>
> Just wondering, but does it run in 32 or 64 bit mode?  I have a
> feeling it's only 32 bit mode ...  Is it compiled for the i386 or
> the x86_64 arch?  Did you have CONFIG_X86_64=y as compile time
> option?

Yes, you are right. Its "only" 32bit (kernel and userland). The Debian
amd64 port team is still working on 64bit packages.

--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org

Re: Call for port reports

From

Bruce Momjian

Date:

25 October 2003, 14:01:44

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,
Pennsylvania19073

Re: Call for port reports

From

Larry Rosenman

Date:

25 October 2003, 14:12:34


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

From

Bruce Momjian

Date:

25 October 2003, 14:13:30

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

25 October 2003, 14:14:53

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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

25 October 2003, 14:24:18

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

From

Larry Rosenman

Date:

25 October 2003, 14:25:59


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

From

Bruce Momjian

Date:

25 October 2003, 14:48:06

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

25 October 2003, 15:46:25

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
Index: configure
===================================================================
RCS file: /cvsroot/pgsql-server/configure,v
retrieving revision 1.306
diff -c -c -r1.306 configure
*** configure    22 Oct 2003 04:16:27 -0000    1.306
--- configure    25 Oct 2003 15:44:00 -0000
***************
*** 2384,2389 ****
--- 2384,2392 ----
  ac_compiler_gnu=$ac_cv_c_compiler_gnu


+ # Strip off -g added by autoconf
+ CFLAGS="`echo \"$CFLAGS\" | sed 's/\( *\)-g\( *\)/\1\2/'`"
+
  #
  # Read the template
  #
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.297
diff -c -c -r1.297 configure.in
*** configure.in    22 Oct 2003 04:16:39 -0000    1.297
--- configure.in    25 Oct 2003 15:44:03 -0000
***************
*** 229,234 ****
--- 229,237 ----

  AC_PROG_CC([$pgac_cc_list])

+ # Strip off -g added by autoconf
+ CFLAGS="`echo \"$CFLAGS\" | sed 's/\( *\)-g\( *\)/\1\2/'`"
+
  #
  # Read the template
  #
Index: src/template/freebsd
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/freebsd,v
retrieving revision 1.27
diff -c -c -r1.27 freebsd
*** src/template/freebsd    9 Oct 2003 22:55:46 -0000    1.27
--- src/template/freebsd    25 Oct 2003 15:44:09 -0000
***************
*** 1,6 ****
! case $host_cpu in
!   alpha*)   CFLAGS="$CFLAGS -O";;  # alpha has problems with -O2
! esac

  THREAD_SUPPORT=yes
  NEED_REENTRANT_FUNCS=yes
--- 1,10 ----
! # alpha has problems with -O2
! # is FreeBSD/Alpha the only gcc Alpha that can't handle -O2?
! if test "$GCC" = yes; then
!     case $host_cpu in
!       alpha*)   CFLAGS="`echo \"$CFLAGS\" | sed 's/\( *\)-O2\( *\)/\1-O\2/'`" ;;
!     esac
! fi

  THREAD_SUPPORT=yes
  NEED_REENTRANT_FUNCS=yes

Re: Call for port reports

From

Peter Eisentraut

Date:

25 October 2003, 16:35:43

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

From

Larry Rosenman

Date:

25 October 2003, 17:07:28


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

From

Noèl Köthe

Date:

25 October 2003, 17:33:52

> 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

here are some build reports. Its all on Debian GNU/Linux with different
architectures:

======================All 93 tests passed.
======================
rm regress.o
make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/pgsql/src/test'
noel@bruckner:~/pgsql$ uname -a
Linux bruckner 2.4.21 #1 Don Aug 28 15:18:52 CEST 2003 ppc GNU/Linux

---------------------------------------------------------------------

In file included from ../../../../src/include/storage/spin.h:50,                from xlog.c:37:
../../../../src/include/storage/s_lock.h:543:2: #error This platform does not support native spinlocks. To continue the
compile,rerun configure using --disable-spinlocks. However, performance will be poor. Please report this to
pgsql-bugs@postgresql.org.
make[4]: *** [xlog.o] Error 1
make[4]: Leaving directory `/home/noel/pgsql/src/backend/access/transam'
make[3]: *** [transam-recursive] Error 2
make[3]: Leaving directory `/home/noel/pgsql/src/backend/access'
make[2]: *** [access-recursive] Error 2
make[2]: Leaving directory `/home/noel/pgsql/src/backend'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/noel/pgsql/src'
make: *** [all] Error 2
noel@paer:~/pgsql$ uname -a
Linux paer 2.4.20-64 #1 Fri Aug 1 23:40:10 UTC 2003 parisc64 GNU/Linux

rebuild with --disable-spinlocks

...    transactions         ... ok    random               ... failed (ignored)    portals              ... ok
...
==================================================92 of 93 tests passed, 1 failed test(s) ignored.
==================================================
The differences that caused some tests to fail can be viewed in the
file `./regression.diffs'.  A copy of the test summary that you see
above is saved in the file `./regression.out'.
rm regress.o
make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/pgsql/src/test'
noel@paer:~/pgsql$ uname -a
Linux paer 2.4.20-64 #1 Fri Aug 1 23:40:10 UTC 2003 parisc64 GNU/Linux

this is regression.diffs:

*** ./expected/random.out       Thu Feb 13 05:24:04 2003
--- ./results/random.out        Fri Oct 24 22:19:29 2003
***************
*** 31,35 ****   WHERE random NOT BETWEEN 80 AND 120;  random --------
! (0 rows)
--- 31,36 ----   WHERE random NOT BETWEEN 80 AND 120;  random --------
!     122
! (1 row)


-----------------------------------------------------------------------

======================All 93 tests passed.
======================
rm regress.o
make[2]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test'
(sid)noel@debussy:~/postgresql-cvs/pgsql$ uname -a
Linux debussy 2.4.19-netwinder #1 Thu Mar 20 03:14:34 CET 2003 armv4l GNU/Linux

--------------------------------------------------------------------------

======================All 93 tests passed.
======================
rm regress.o
make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/pgsql/src/test'
noel@merulo:~/pgsql$ uname -a
Linux merulo 2.4.18-itanium-smp #1 SMP Sat Nov 23 01:39:07 MST 2002 ia64 GNU/Linux

----------------------------------------------------------------------------

...    transactions         ... ok    random               ... failed (ignored)    portals              ... ok
...
==================================================92 of 93 tests passed, 1 failed test(s) ignored.
==================================================
The differences that caused some tests to fail can be viewed in the
file `./regression.diffs'.  A copy of the test summary that you see
above is saved in the file `./regression.out'.
rm regress.o
make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/pgsql/src/test'
(unstable)noel@raptor:~/pgsql$ uname -a
Linux raptor 2.4.19 #1 SMP Fri Nov 29 23:53:27 CET 2002 s390 GNU/Linux

------------------------------------------------------------------------------

reports of these slower systems will follow but they need a bit more time:

Linux casals 2.4.19-r4k-ip22 #1 Tue Mar 18 15:38:10 CET 2003 mips unknown
Linux crest 2.4.20 #1 Wed Mar 5 01:39:17 EST 2003 m68k unknown
Linux escher 2.4.22 #2 Sat Sep 6 18:23:54 CEST 2003 alpha GNU/Linux

--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org

Re: Call for port reports

From

Hans-Jürgen Schönig

Date:

25 October 2003, 17:34:45

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

From

Peter Eisentraut

Date:

25 October 2003, 20:24:46

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

From

Peter Eisentraut

Date:

25 October 2003, 20:29:35

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

From

Noèl Köthe

Date:

25 October 2003, 20:52:53

Am Sa, den 25.10.2003 schrieb Noèl Köthe um 01:17:

> reports of these slower systems will follow but they need a bit more time:

> Linux crest 2.4.20 #1 Wed Mar 5 01:39:17 EST 2003 m68k unknown

Peter gave me this patch for m68k:

-- src/include/port/linux.h.orig       Sat Oct 25 13:45:44 2003
+++ src/include/port/linux.h    Sat Oct 25 12:21:41 2003
@@ -45,3 +45,8 @@
#endif
+#if defined(__mc68000__)
+#define HAS_TEST_AND_SET
+typedef unsigned char slock_t;
+#endif
+

======================All 93 tests passed.
======================
rm regress.o
make[2]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test'
(unstable)noel@crest:~/postgresql-cvs/pgsql$ uname -a
Linux crest 2.4.20 #1 Wed Mar 5 01:39:17 EST 2003 m68k GNU/Linux

> Linux escher 2.4.22 #2 Sat Sep 6 18:23:54 CEST 2003 alpha GNU/Linux

======================
All 93 tests passed.
======================

rm regress.o
make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
make[1]: Leaving directory `/home/noel/pgsql/src/test'
noel@escher:~/pgsql$ uname -a
Linux escher 2.4.22 #2 Sat Sep 6 18:23:54 CEST 2003 alpha GNU/Linux



--

Noèl Köthe <noel@debian.org>

Debian GNU/Linux, www.debian.org

Re: Call for port reports

From

Peter Eisentraut

Date:

25 October 2003, 21:33:46

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

From

Larry Rosenman

Date:

25 October 2003, 21:38:39


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

From

Johan Henselmans

Date:

25 October 2003, 21:52:48

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

From

Kevin Brown

Date:

25 October 2003, 22:27:17

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

From

Andrew Dunstan

Date:

25 October 2003, 22:40:37


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

From

Bruce Momjian

Date:

26 October 2003, 00:01:39

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 00:02:36

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 00:12:55

I can't certify the following platform because it doesn't recognize our
spinlock code.  Would you run src/tools/ccsym and report back the
symbols you have.  Do you not have __powerpc__ defined?

The actual test in s_lock.h is:
#if defined(__ppc__) || defined(__powerpc__) || defined(__powerpc64__)

but src/include/port/linux.h only tests for the last two --- this is a
mismatch we are going to clean up for 7.5, but I need to know what your
compiler defines.

---------------------------------------------------------------------------

No�l K�the wrote:
-- Start of PGP signed section.
> 
> > 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
> 
> here are some build reports. Its all on Debian GNU/Linux with different
> architectures:
> 
> ======================
>  All 93 tests passed.
> ======================
>  
> rm regress.o
> make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/pgsql/src/test'
> noel@bruckner:~/pgsql$ uname -a
> Linux bruckner 2.4.21 #1 Don Aug 28 15:18:52 CEST 2003 ppc GNU/Linux
> 
> ---------------------------------------------------------------------
> 
> In file included from ../../../../src/include/storage/spin.h:50,
>                  from xlog.c:37:
> ../../../../src/include/storage/s_lock.h:543:2: #error This platform does not support native spinlocks. To continue
thecompile, rerun configure using --disable-spinlocks. However, performance will be poor. Please report this to
pgsql-bugs@postgresql.org.
> make[4]: *** [xlog.o] Error 1
> make[4]: Leaving directory `/home/noel/pgsql/src/backend/access/transam'
> make[3]: *** [transam-recursive] Error 2
> make[3]: Leaving directory `/home/noel/pgsql/src/backend/access'
> make[2]: *** [access-recursive] Error 2
> make[2]: Leaving directory `/home/noel/pgsql/src/backend'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/noel/pgsql/src'
> make: *** [all] Error 2
> noel@paer:~/pgsql$ uname -a
> Linux paer 2.4.20-64 #1 Fri Aug 1 23:40:10 UTC 2003 parisc64 GNU/Linux
> 
> rebuild with --disable-spinlocks
> 
> ...
>      transactions         ... ok
>      random               ... failed (ignored)
>      portals              ... ok
> ...
> ==================================================
>  92 of 93 tests passed, 1 failed test(s) ignored.
> ==================================================
>  
> The differences that caused some tests to fail can be viewed in the
> file `./regression.diffs'.  A copy of the test summary that you see
> above is saved in the file `./regression.out'.
>  
> rm regress.o
> make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/pgsql/src/test'
> noel@paer:~/pgsql$ uname -a
> Linux paer 2.4.20-64 #1 Fri Aug 1 23:40:10 UTC 2003 parisc64 GNU/Linux
> 
> this is regression.diffs:
> 
> *** ./expected/random.out       Thu Feb 13 05:24:04 2003
> --- ./results/random.out        Fri Oct 24 22:19:29 2003
> ***************
> *** 31,35 ****
>     WHERE random NOT BETWEEN 80 AND 120;
>    random
>   --------
> ! (0 rows)
>    
> --- 31,36 ----
>     WHERE random NOT BETWEEN 80 AND 120;
>    random
>   --------
> !     122
> ! (1 row)
> 

--  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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 00:21:06

Would someone help me getting this persons name into SGML?
No?l K?the <noel@debian.org>

I am not sure how to transfer that encoding into SGML.

> ======================
>  All 93 tests passed.
> ======================
>  
> rm regress.o
> make[2]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test'
> (sid)noel@debussy:~/postgresql-cvs/pgsql$ uname -a
> Linux debussy 2.4.19-netwinder #1 Thu Mar 20 03:14:34 CET 2003 armv4l GNU/Linux


Ports list updated:
 http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html


> --------------------------------------------------------------------------
> 
> ======================
>  All 93 tests passed.
> ======================
>  
> rm regress.o
> make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/pgsql/src/test'
> noel@merulo:~/pgsql$ uname -a
> Linux merulo 2.4.18-itanium-smp #1 SMP Sat Nov 23 01:39:07 MST 2002 ia64 GNU/Linux

Updated.

> ----------------------------------------------------------------------------
> 
> ...
>      transactions         ... ok
>      random               ... failed (ignored)
>      portals              ... ok
> ...
> ==================================================
>  92 of 93 tests passed, 1 failed test(s) ignored.
> ==================================================
>  
> The differences that caused some tests to fail can be viewed in the
> file `./regression.diffs'.  A copy of the test summary that you see
> above is saved in the file `./regression.out'.
>  
> rm regress.o
> make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/pgsql/src/test'
> (unstable)noel@raptor:~/pgsql$ uname -a
> Linux raptor 2.4.19 #1 SMP Fri Nov 29 23:53:27 CET 2002 s390 GNU/Linux


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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

26 October 2003, 00:21:58

Bruce Momjian writes:

> I can't certify the following platform because it doesn't recognize our
> spinlock code.  Would you run src/tools/ccsym and report back the
> symbols you have.  Do you not have __powerpc__ defined?

The way I read his report (a little tricky to find the divisions) is that
ppc has passed and parisc64 doesn't have spinlock code, which sounds a
lot more credible.

-- 
Peter Eisentraut   peter_e@gmx.net

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 00:29:59

No�l K�the wrote:
-- Start of PGP signed section.
> Am Sa, den 25.10.2003 schrieb No?l K?the um 01:17:
>
> > reports of these slower systems will follow but they need a bit more time:
> >
> > Linux casals 2.4.19-r4k-ip22 #1 Tue Mar 18 15:38:10 CET 2003 mips unknown
>
>      polymorphism         ... ok
>      stats                ... ok
> ============== shutting down postmaster               ==============


Ports list updated:

  http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html

>
> ======================
>  All 93 tests passed.
> ======================
>
> rm regress.o
> make[2]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test'
> noel@casals:~/postgresql-cvs/pgsql$ uname -a
> Linux casals 2.4.19-r4k-ip22 #1 Tue Mar 18 15:38:10 CET 2003 mips GNU/Linux
>
> > Linux crest 2.4.20 #1 Wed Mar 5 01:39:17 EST 2003 m68k unknown
>
> gcc -g -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include
-D_GNU_SOURCE  -c -o xlog.o xlog.c 
> In file included from ../../../../src/include/storage/spin.h:50,
>                  from xlog.c:37:
> ../../../../src/include/storage/s_lock.h:543:2: #error This platform does not support native spinlocks. To continue
thecompile, rerun configure using --disable-spinlocks. However, performance will be poor. Please report this to
pgsql-bugs@postgresql.org.
> make[4]: *** [xlog.o] Error 1
> make[4]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/backend/access/transam'

OK, this port has the same problem with the include/port/*.h files not
matching the s_lock.h files.  I knew this would bite us but we didn't
want to risk a reorganization during beta.

The following patch has been applied and should allow m68k to work ---
please report back.

--
  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
Index: src/include/port/linux.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/port/linux.h,v
retrieving revision 1.35
diff -c -c -r1.35 linux.h
*** src/include/port/linux.h    26 Sep 2003 17:39:13 -0000    1.35
--- src/include/port/linux.h    26 Oct 2003 00:24:27 -0000
***************
*** 43,46 ****
--- 43,51 ----

  #define HAS_TEST_AND_SET

+ #elif defined(__m68k__)
+ typedef unsigned char slock_t;
+
+ #define HAS_TEST_AND_SET
+
  #endif

Re: Call for port reports

From

Peter Eisentraut

Date:

26 October 2003, 00:31:46

Bruce Momjian writes:

> Would someone help me getting this persons name into SGML?
>
>     No?l K?the <noel@debian.org>
>
> I am not sure how to transfer that encoding into SGML.

Noèl Köthe

-- 
Peter Eisentraut   peter_e@gmx.net

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 00:33:01

Ports list updated:
 http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html

Again, I need help converting this name to SGML.

---------------------------------------------------------------------------

Hans-J�rgen Sch�nig 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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 00:35:37

Dave Page wrote:
>  
> 
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] 
> > Sent: 24 October 2003 16:38
> > To: PostgreSQL-development
> > Subject: [HACKERS] Call for port reports
> > 
> > It is time for people to report their port testing.  Please 
> > test against current CVS or beta5 and report your 'uname -a'.
> 
> Cygwin
> ======
> 
> Parallel regression tests do not complete (we normally have problems
> with these anyway, though they do normally complete).
> 
> Serial tests pass.
> 
> CYGWIN_NT-5.1 pc30 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown
> Cygwin
> 

Uh, I am not inclined to mark the port as OK if the parallel regression
tests fail --- what is the cause?

> Win32 Client
> ============
> 
> (Windows XP Pro, VC++ 6.0)
> 
> C:\cygwin\usr\local\src\postgresql-7.4beta5\src>nmake /f win32.mak ALL
> 
> Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
> 
>         cd include
>         if not exist pg_config.h copy pg_config.h.win32 pg_config.h
>         cd ..
>         cd interfaces\libpq
>         nmake /f win32.mak
> 
> Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
> 
> Building the Win32 static library...
> 
>         cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nma02744.
> getaddrinfo.c
> ..\..\include\c.h(66) : fatal error C1083: Cannot open include file:
> 'strings.h'
> : No such file or directory
> NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' :
> return co
> de '0x2'
> Stop.

I am confused why strings.h is being included because there is a test
around it:#ifdef HAVE_STRINGS_H#include <strings.h>#endif

Any ideas?

--  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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 00:39:27

No�l K�the wrote:
-- Start of PGP signed section.
> Am Sa, den 25.10.2003 schrieb No?l K?the um 01:17:
> > > 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
> > 
> > here are some build reports. Its all on Debian GNU/Linux with different
> > architectures:
> 
> ======================
>  All 93 tests passed.
> ======================
>  
> rm regress.o
> make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/pgsql/src/test'
> noel@pergolesi:~/pgsql$ uname -a
> Linux pergolesi 2.4.22 #1 SMP Mon Aug 25 20:56:25 CEST 2003 i686 GNU/Linux
> 
> It says i686 but its AMD Opteron:
> 
> noel@pergolesi:~/pgsql$ cat /proc/cpuinfo |more
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 15
> model           : 5
> model name      : AMD Opteron(tm) Processor 240
> stepping        : 1
> cpu MHz         : 1394.299
> cache size      : 1024 KB
> ...

I am confused how to handle this.  Is this running in 32-bit mode?  I am
inclined to mention Opteron only when tested in 64-bit mode, because I
think we all assume a 32-bit Opteron is the same as a standard
AMD/Intel.  Does uname report differently in 64-bit mode.

--  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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 00:43:13

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 00:44:17

No�l K�the wrote:
-- Start of PGP signed section.
> Am Sa, den 25.10.2003 schrieb Kurt Roeckx um 13:48:
> 
> > > Linux pergolesi 2.4.22 #1 SMP Mon Aug 25 20:56:25 CEST 2003 i686 GNU/Linux
> > > 
> > > It says i686 but its AMD Opteron:
> > 
> > Just wondering, but does it run in 32 or 64 bit mode?  I have a
> > feeling it's only 32 bit mode ...  Is it compiled for the i386 or
> > the x86_64 arch?  Did you have CONFIG_X86_64=y as compile time
> > option?
> 
> Yes, you are right. Its "only" 32bit (kernel and userland). The Debian
> amd64 port team is still working on 64bit packages.

OK, I don't think we will mention 32-bit Opteron separately --- it could
probably cause confusion if we didn't mention it for all platforms.

--  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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

26 October 2003, 00:45:37

Bruce Momjian writes:

> The following patch has been applied and should allow m68k to work ---
> please report back.

Won't work.  Please see his last mail for the right patch.

-- 
Peter Eisentraut   peter_e@gmx.net

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 00:46:20

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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

26 October 2003, 00:50:26

Bruce Momjian writes:

> Uh, I am not inclined to mark the port as OK if the parallel regression
> tests fail --- what is the cause?

They always have been on Cygwin.  This platform just can't handle that
many parallel connections.

-- 
Peter Eisentraut   peter_e@gmx.net

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:05:14

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:07:20

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:21:18

Ports list updated:
 http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html

m68k patch already applied.

---------------------------------------------------------------------------

No�l K�the wrote:
-- Start of PGP signed section.
> Am Sa, den 25.10.2003 schrieb No?l K?the um 01:17:
> 
> > reports of these slower systems will follow but they need a bit more time:
> 
> > Linux crest 2.4.20 #1 Wed Mar 5 01:39:17 EST 2003 m68k unknown
> 
> Peter gave me this patch for m68k:
> 
> -- src/include/port/linux.h.orig       Sat Oct 25 13:45:44 2003
> +++ src/include/port/linux.h    Sat Oct 25 12:21:41 2003
> @@ -45,3 +45,8 @@
>   
> #endif
>   
> +#if defined(__mc68000__)
> +#define HAS_TEST_AND_SET
> +typedef unsigned char slock_t;
> +#endif
> +
> 
> ======================
>  All 93 tests passed.
> ======================
>  
> rm regress.o
> make[2]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test'
> (unstable)noel@crest:~/postgresql-cvs/pgsql$ uname -a
> Linux crest 2.4.20 #1 Wed Mar 5 01:39:17 EST 2003 m68k GNU/Linux
> 
> > Linux escher 2.4.22 #2 Sat Sep 6 18:23:54 CEST 2003 alpha GNU/Linux
> 
> ======================
> All 93 tests passed.
> ======================
> 
> rm regress.o
> make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/pgsql/src/test'
> noel@escher:~/pgsql$ uname -a
> Linux escher 2.4.22 #2 Sat Sep 6 18:23:54 CEST 2003 alpha GNU/Linux
> 
> 
> 
> -- 
> 
> No?l K?the <noel@debian.org>
> 
> Debian GNU/Linux, www.debian.org
-- 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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:22:03

Ports list updated:
 http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html

m68k patch already applied.

---------------------------------------------------------------------------

No�l K�the wrote:
-- Start of PGP signed section.
> Am Sa, den 25.10.2003 schrieb No?l K?the um 01:17:
> 
> > reports of these slower systems will follow but they need a bit more time:
> 
> > Linux crest 2.4.20 #1 Wed Mar 5 01:39:17 EST 2003 m68k unknown
> 
> Peter gave me this patch for m68k:
> 
> -- src/include/port/linux.h.orig       Sat Oct 25 13:45:44 2003
> +++ src/include/port/linux.h    Sat Oct 25 12:21:41 2003
> @@ -45,3 +45,8 @@
>   
> #endif
>   
> +#if defined(__mc68000__)
> +#define HAS_TEST_AND_SET
> +typedef unsigned char slock_t;
> +#endif
> +
> 
> ======================
>  All 93 tests passed.
> ======================
>  
> rm regress.o
> make[2]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/postgresql-cvs/pgsql/src/test'
> (unstable)noel@crest:~/postgresql-cvs/pgsql$ uname -a
> Linux crest 2.4.20 #1 Wed Mar 5 01:39:17 EST 2003 m68k GNU/Linux
> 
> > Linux escher 2.4.22 #2 Sat Sep 6 18:23:54 CEST 2003 alpha GNU/Linux
> 
> ======================
> All 93 tests passed.
> ======================
> 
> rm regress.o
> make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/pgsql/src/test'
> noel@escher:~/pgsql$ uname -a
> Linux escher 2.4.22 #2 Sat Sep 6 18:23:54 CEST 2003 alpha GNU/Linux
> 
> 
> 
> -- 
> 
> No?l K?the <noel@debian.org>
> 
> Debian GNU/Linux, www.debian.org
-- 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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:30:36

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:33:26

No�l K�the wrote:
-- Start of PGP signed section.
> 
> > 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
> 
> here are some build reports. Its all on Debian GNU/Linux with different
> architectures:
> 
> ======================
>  All 93 tests passed.
> ======================
>  
> rm regress.o
> make[2]: Leaving directory `/home/noel/pgsql/src/test/regress'
> make[1]: Leaving directory `/home/noel/pgsql/src/test'
> noel@bruckner:~/pgsql$ uname -a
> Linux bruckner 2.4.21 #1 Don Aug 28 15:18:52 CEST 2003 ppc GNU/Linux

Ports list updated:
 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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:38:57

Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > I can't certify the following platform because it doesn't recognize our
> > spinlock code.  Would you run src/tools/ccsym and report back the
> > symbols you have.  Do you not have __powerpc__ defined?
> 
> The way I read his report (a little tricky to find the divisions) is that
> ppc has passed and parisc64 doesn't have spinlock code, which sounds a
> lot more credible.

Oh, I see now --- sorry.

Wow, I looked in hpux.h and saw:#if defined(__hppa)#define HAS_TEST_AND_SETtypedef struct{    int         sema[4];}
slock_t;#ifndef        BYTE_ORDER#define         BYTE_ORDER      BIG_ENDIAN#endif
 

and I see in s_lock.h:#if defined(__hppa)/* * HP's PA-RISC * * Note that slock_t on PA-RISC is a structure instead of
char* (see include/port/hpux.h). * * a "set" slock_t has a single word cleared.  a "clear" slock_t has * all words set
tonon-zero. tas() is in tas.s */#define S_UNLOCK(lock) \    do { \        volatile slock_t *lock_ = (volatile slock_t
*)(lock); \        lock_->sema[0] = -1; \        lock_->sema[1] = -1; \        lock_->sema[2] = -1; \
lock_->sema[3]= -1; \    } while (0)#define S_LOCK_FREE(lock)   ( *(int *) (((long) (lock) + 15) & ~15) != 0)#endif
/*__hppa */
 

Can Linux handle this?  Can you copy the stuff from hpux.h and see if
that works for Linux?

We can't mark this port as working unless we have spinlocks.

--  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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:40:40

Thanks.  SGML updated.

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > Would someone help me getting this persons name into SGML?
> >
> >     No?l K?the <noel@debian.org>
> >
> > I am not sure how to transfer that encoding into SGML.
> 
> Noèl Köthe
> 
> -- 
> 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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:42:11

Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > The following patch has been applied and should allow m68k to work ---
> > please report back.
> 
> Won't work.  Please see his last mail for the right patch.

Got it --- applied --- __mc68000__.

--  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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:43:43

Dave Page wrote:
>  
> 
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] 
> > Sent: 24 October 2003 16:38
> > To: PostgreSQL-development
> > Subject: [HACKERS] Call for port reports
> > 
> > It is time for people to report their port testing.  Please 
> > test against current CVS or beta5 and report your 'uname -a'.
> 
> Cygwin
> ======
> 
> Parallel regression tests do not complete (we normally have problems
> with these anyway, though they do normally complete).
> 
> Serial tests pass.
> 
> CYGWIN_NT-5.1 pc30 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown
> Cygwin

Cygwin marked as completed by Peter.  Thanks.

--  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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 01:48:47

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,
Pennsylvania19073

Re: Call for port reports

From

Noèl Köthe

Date:

26 October 2003, 06:59:08

Am So, den 26.10.2003 schrieb Bruce Momjian um 02:20:

> > (unstable)noel@raptor:~/pgsql$ uname -a
> > Linux raptor 2.4.19 #1 SMP Fri Nov 29 23:53:27 CET 2002 s390 GNU/Linux
>
> Updated.

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

Thx. Just a minor thing. The version of s/390 should be 7.4 and not 7.3.
(maybe the same with OpenBSD/x86?)

--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org

Re: Call for port reports

From

Christopher Kings-Lynne

Date:

26 October 2003, 07:18:29

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

From

Kurt Roeckx

Date:

26 October 2003, 09:42:36

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

From

"Dave Page"

Date:

26 October 2003, 09:44:07

It's rumoured that Peter Eisentraut once said:
> Bruce Momjian writes:
>
>> Uh, I am not inclined to mark the port as OK if the parallel
>> regression tests fail --- what is the cause?
>
> They always have been on Cygwin.  This platform just can't handle that
> many parallel connections.

Previously though that just resulted in a few failed tests - the run
always completed. This time I'm seeing it hang at some random point in the
tests. The one difference between now and when I've run tests previously
is that I'm now running a centrino laptop.
I'll see if I can spend some more time on it later, though I have a very
large project going live on Monday so finding time might be tricky :-(
Regards, Dave.

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 12:23:30

No�l K�the wrote:
-- Start of PGP signed section.
> Am So, den 26.10.2003 schrieb Bruce Momjian um 02:20:
> 
> > > (unstable)noel@raptor:~/pgsql$ uname -a
> > > Linux raptor 2.4.19 #1 SMP Fri Nov 29 23:53:27 CET 2002 s390 GNU/Linux
> > 
> > Updated.
> 
> http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html
> 
> Thx. Just a minor thing. The version of s/390 should be 7.4 and not 7.3.
> (maybe the same with OpenBSD/x86?)

Yep, fixed, and Freebsd/alpha too.
--  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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 12:24:51

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 12:27:53

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

26 October 2003, 12:29:58

Dave Page wrote:
> It's rumoured that Peter Eisentraut once said:
> > Bruce Momjian writes:
> >
> >> Uh, I am not inclined to mark the port as OK if the parallel
> >> regression tests fail --- what is the cause?
> >
> > They always have been on Cygwin.  This platform just can't handle that
> > many parallel connections.
> 
> Previously though that just resulted in a few failed tests - the run
> always completed. This time I'm seeing it hang at some random point in the
> tests. The one difference between now and when I've run tests previously
> is that I'm now running a centrino laptop.
> I'll see if I can spend some more time on it later, though I have a very
> large project going live on Monday so finding time might be tricky :-(
> Regards, Dave.

No problem --- the port is already marked as working --- this is a known
problem with the parallel tests.

--  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,
Pennsylvania19073

Re: Call for port reports

From

Kurt Roeckx

Date:

26 October 2003, 13:15:41

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

From

Bruce Momjian

Date:

26 October 2003, 13:32:06

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,
Pennsylvania19073

Re: Call for port reports

From

"Dave Page"

Date:

26 October 2003, 16:34:49


> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: 26 October 2003 13:29
> To: Dave Page
> Cc: peter_e@gmx.net; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Call for port reports
>
> > Previously though that just resulted in a few failed tests
> - the run
> > always completed. This time I'm seeing it hang at some
> random point in
> > the tests. The one difference between now and when I've run tests
> > previously is that I'm now running a centrino laptop.
> > I'll see if I can spend some more time on it later, though I have a
> > very large project going live on Monday so finding time might be
> > tricky :-( Regards, Dave.
>
> No problem --- the port is already marked as working --- this
> is a known problem with the parallel tests.

No it's not, that's what I'm saying. Normally the tests finish with a
few failures (because Cygwin can't create enough sockets). I'm seeing a
full blown hang.

Regards, Dave.

Re: Call for port reports

From

"Dave Page"

Date:

26 October 2003, 19:22:38


> -----Original Message-----
> From: Dave Page
> Sent: 26 October 2003 17:34
> To: Bruce Momjian
> Cc: peter_e@gmx.net; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Call for port reports
>
>
> > No problem --- the port is already marked as working --- this is a
> > known problem with the parallel tests.
>
> No it's not, that's what I'm saying. Normally the tests
> finish with a few failures (because Cygwin can't create
> enough sockets). I'm seeing a full blown hang.
>

OK, cleaned up and rebuilt & it looks OK now (well, as OK as it ever
does on XP Pro).

Regards, Dave.

Re: Call for port reports / test horology FAILED

From

Tilo Schwarz

Date:

26 October 2003, 21:02:35

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

From

"Andrew Dunstan"

Date:

26 October 2003, 23:11:21

----- Original Message ----- 
From: "Dave Page" <dpage@vale-housing.co.uk>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: <peter_e@gmx.net>; <pgsql-hackers@postgresql.org>
Sent: Sunday, October 26, 2003 3:22 PM
Subject: Re: [HACKERS] Call for port reports


>
>
> > -----Original Message-----
> > From: Dave Page
> > Sent: 26 October 2003 17:34
> > To: Bruce Momjian
> > Cc: peter_e@gmx.net; pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Call for port reports
> >
> >
> > > No problem --- the port is already marked as working --- this is a
> > > known problem with the parallel tests.
> >
> > No it's not, that's what I'm saying. Normally the tests
> > finish with a few failures (because Cygwin can't create
> > enough sockets). I'm seeing a full blown hang.
> >
>
> OK, cleaned up and rebuilt & it looks OK now (well, as OK as it ever
> does on XP Pro).
>

I am seeing these hangs consistently (but not always in the same place) on
XPHE running on a P4.

uname: CYGWIN_NT-5.1 DUNSLANE 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown
unknown Cygwin

cheers

andrew

Re: Call for port reports

From

Bruce Momjian

Date:

27 October 2003, 01:36:03

Dave Page wrote:
>  
> 
> > -----Original Message-----
> > From: Dave Page 
> > Sent: 26 October 2003 17:34
> > To: Bruce Momjian
> > Cc: peter_e@gmx.net; pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Call for port reports
> > 
> >  
> > > No problem --- the port is already marked as working --- this is a 
> > > known problem with the parallel tests.
> > 
> > No it's not, that's what I'm saying. Normally the tests 
> > finish with a few failures (because Cygwin can't create 
> > enough sockets). I'm seeing a full blown hang.
> >
> 
> OK, cleaned up and rebuilt & it looks OK now (well, as OK as it ever
> does on XP Pro).

OK, thanks.

--  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,
Pennsylvania19073

Re: Call for port reports / test horology FAILED

From

Bruce Momjian

Date:

27 October 2003, 01:55:44

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,
Pennsylvania19073

Re: Call for port reports

From

Neil Conway

Date:

27 October 2003, 08:58:08

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
noline numbers.

  Level 3 includes extra information, such as all the macro defini-  tions present in the program.  Some debuggers
supportmacro 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
aconcatenated  debug level.  Instead use an additional -glevel option to change  the debug level for DWARF1 or DWARF2.

-Neil

Re: Call for port reports

From

Tom Lane

Date:

28 October 2003, 23:41:18

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

From

Sean Chittenden

Date:

29 October 2003, 00:14:06

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

From

Alessio Bragadini

Date:

29 October 2003, 10:46:27

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

From

Bruce Momjian

Date:

29 October 2003, 12:43:47

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,
Pennsylvania19073

opteron port [was: Re: Call for port reports]

From

Noèl Köthe

Date:

30 October 2003, 13:42:25

Am So, den 26.10.2003 schrieb Bruce Momjian um 02:38:

> >  All 93 tests passed.
...
> > Linux pergolesi 2.4.22 #1 SMP Mon Aug 25 20:56:25 CEST 2003 i686 GNU/Linux
> >
> > It says i686 but its AMD Opteron:
> >
> > noel@pergolesi:~/pgsql$ cat /proc/cpuinfo |more
...
> > model name      : AMD Opteron(tm) Processor 240
...
> I am confused how to handle this.  Is this running in 32-bit mode?  I am
> inclined to mention Opteron only when tested in 64-bit mode, because I
> think we all assume a 32-bit Opteron is the same as a standard
> AMD/Intel.  Does uname report differently in 64-bit mode.

You are right. Its now just like an i386 so it doesn't make sense to
list it. When I will get access to an 64bit Opteron system I will test
it again.

--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org

Re: Call for port reports

From

Tom Lane

Date:

31 October 2003, 04:02:36

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

From

Peter Eisentraut

Date:

31 October 2003, 09:41:05

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 uint32calc_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 DatummyFunctionCall2(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
directionproperly. */
 
-static inline int32
+static int32inlineApplySortFunction(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

From

Tom Lane

Date:

31 October 2003, 14:58:30

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

From

Tom Lane

Date:

31 October 2003, 15:09:50

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

From

Bruce Momjian

Date:

31 October 2003, 15:21:44

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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

31 October 2003, 15:37:45

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
allowthat.

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

From

Tom Lane

Date:

31 October 2003, 16:03:42

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

From

Bruce Momjian

Date:

31 October 2003, 20:26:13

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,
Pennsylvania19073

Re: Call for port reports

From

Peter Eisentraut

Date:

01 November 2003, 02:36:43

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

From

Peter Eisentraut

Date:

04 November 2003, 09:10:04

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

From

Bruce Momjian

Date:

08 November 2003, 22:37:11

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,
Pennsylvania19073

Re: Call for port reports

From

Bruce Momjian

Date:

09 November 2003, 01:03:30

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,
Pennsylvania19073

Re: Call for port reports

From

Kurt Roeckx

Date:

09 November 2003, 01:24:30

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

From

Tom Lane

Date:

09 November 2003, 03:03:17

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