Re: 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'.

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On 24/10/03 4:37 pm, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)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.

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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net

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(at)gmx(dot)net

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(at)gmx(dot)net
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net

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(at)gmx(dot)net

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

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

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 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(at)gmx(dot)net

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(at)gmx(dot)net

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

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(at)gmx(dot)net
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > It is time for people to report their port testing. Please test against
> > current CVS or beta5 and report your 'uname -a'.
>
> This one is OK:
>
> FreeBSD 4.8-RELEASE alpha
>
> BUT: The default CFLAGS are set by configure to -O2, although the template
> wants -O. I manually modified the CFLAGS to -O after configure.

template/alpha has:

case $host_cpu in
alpha*) CFLAGS="$CFLAGS -O";; # alpha has problems with -O2
esac

Is this not getting invoked?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net

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(at)gmx(dot)net
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

pgman(at)candle(dot)pha(dot)pa(dot)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(at)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)

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(at)gmx(dot)net

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

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(at)gmx(dot)net

In the last exciting episode, pgman(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) wrote:
> It is time for people to report their port testing. Please test against
> current CVS or beta5 and report your 'uname -a'.
>
> The current list is at:
>
> http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

On AIX, it's _close_...
============== shutting down postmaster ==============

=======================
1 of 93 tests failed.
=======================

bash-2.05a$ uname -a
AIX ibm-db 1 5 000CD13A4C00

The difference lies here:

bash-2.05a$ more regress/regression.diffs
*** ./expected/errors.out Wed Oct 1 17:07:24 2003
--- ./results/errors.out Fri Oct 24 17:56:34 2003
***************
*** 197,211 ****
ERROR: syntax error at or near ")" at character 20
-- no such operator
drop operator === (int4);
! ERROR: missing argument
! HINT: Use NONE to denote the missing argument of a unary operator.
-- no such operator by that name
drop operator === (int4, int4);
ERROR: operator does not exist: integer === integer
-- no such type1
drop operator = (nonesuch);
! ERROR: missing argument
! HINT: Use NONE to denote the missing argument of a unary operator.
-- no such type1
drop operator = ( , int4);
ERROR: syntax error at or near "," at character 19
--- 197,209 ----
ERROR: syntax error at or near ")" at character 20
-- no such operator
drop operator === (int4);
! ERROR: argument type missing (use NONE for unary operators)
-- no such operator by that name
drop operator === (int4, int4);
ERROR: operator does not exist: integer === integer
-- no such type1
drop operator = (nonesuch);
! ERROR: argument type missing (use NONE for unary operators)
-- no such type1
drop operator = ( , int4);
ERROR: syntax error at or near "," at character 19

======================================================================

I'll have to look at "why" next week; I don't see the dropping of a
HINT message being a dramatic error, though.
--
(format nil "~S(at)~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(at)student(dot)dtu(dot)dk>

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

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(at)gmx(dot)net

On Fri, Oct 24, 2003 at 06:07:40PM -0400, Christopher Browne wrote:
> In the last exciting episode, pgman(at)candle(dot)pha(dot)pa(dot)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)

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(at)gmx(dot)net

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(at)gnu(dot)org(dot) ##
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

Ports list updated:

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

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

Christopher Browne wrote:
> pgman(at)candle(dot)pha(dot)pa(dot)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(at)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

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(at)gmx(dot)net

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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

--On Saturday, October 25, 2003 10:00:59 -0400 Bruce Momjian
<pgman(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

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(at)candle(dot)pha(dot)pa(dot)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 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net

--On Saturday, October 25, 2003 10:14:14 -0400 Bruce Momjian
<pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net

--On Saturday, October 25, 2003 18:35:06 +0200 Peter Eisentraut
<peter_e(at)gmx(dot)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(at)gmx(dot)net
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

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(at)gmx(dot)net

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(at)gmx(dot)net

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(at)gmx(dot)net

--On Saturday, October 25, 2003 22:29:04 +0200 Peter Eisentraut
<peter_e(at)gmx(dot)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(at)gmx(dot)net

here ya go:
Script started on Sat Oct 25 16:34:24 2003
$ psql -s reg? ?? ?? ?-U p? ?ler regression
Welcome to psql 7.4beta5, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

regression=# \i privileges.sql
***(Single step mode: verify
command)*******************************************
CREATE USER regressuser1;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:5: ERROR: user "regressuser1" already exists
***(Single step mode: verify
command)*******************************************
CREATE USER regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:6: ERROR: user "regressuser2" already exists
***(Single step mode: verify
command)*******************************************
CREATE USER regressuser3;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:7: ERROR: user "regressuser3" already exists
***(Single step mode: verify
command)*******************************************
CREATE USER regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:8: ERROR: user "regressuser4" already exists
***(Single step mode: verify
command)*******************************************
CREATE USER regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:9: ERROR: user "regressuser4" already exists
***(Single step mode: verify
command)*******************************************
CREATE GROUP regressgroup1;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:11: ERROR: group "regressgroup1" already exists
***(Single step mode: verify
command)*******************************************
CREATE GROUP regressgroup2 WITH USER regressuser1, regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:12: ERROR: group "regressgroup2" already exists
***(Single step mode: verify
command)*******************************************
ALTER GROUP regressgroup1 ADD USER regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

ALTER GROUP
***(Single step mode: verify
command)*******************************************
ALTER GROUP regressgroup2 ADD USER regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

ALTER GROUP
***(Single step mode: verify
command)*******************************************
ALTER GROUP regressgroup2 DROP USER regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

ALTER GROUP
***(Single step mode: verify
command)*******************************************
ALTER GROUP regressgroup2 ADD USER regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

ALTER GROUP
***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser1;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
SELECT session_user, current_user;
***(press return to proceed or enter x and return to
cancel)********************

session_user | current_user
--------------+--------------
regressuser1 | regressuser1
(1 row)

***(Single step mode: verify
command)*******************************************
CREATE TABLE atest1 ( a int, b text );
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:26: ERROR: relation "atest1" already exists
***(Single step mode: verify
command)*******************************************
SELECT * FROM atest1;
***(press return to proceed or enter x and return to
cancel)********************

a | b
---+-----
1 | two
1 | two
(2 rows)

***(Single step mode: verify
command)*******************************************
INSERT INTO atest1 VALUES (1, 'one');
***(press return to proceed or enter x and return to
cancel)********************

INSERT 2356104 1
***(Single step mode: verify
command)*******************************************
DELETE FROM atest1;
***(press return to proceed or enter x and return to
cancel)********************

DELETE 3
***(Single step mode: verify
command)*******************************************
UPDATE atest1 SET a = 1 WHERE b = 'blech';
***(press return to proceed or enter x and return to
cancel)********************

UPDATE 0
***(Single step mode: verify
command)*******************************************
LOCK atest1 IN ACCESS EXCLUSIVE MODE;
***(press return to proceed or enter x and return to
cancel)********************

LOCK TABLE
***(Single step mode: verify
command)*******************************************
REVOKE ALL ON atest1 FROM PUBLIC;
***(press return to proceed or enter x and return to
cancel)********************

REVOKE
***(Single step mode: verify
command)*******************************************
SELECT * FROM atest1;
***(press return to proceed or enter x and return to
cancel)********************

a | b
---+---
(0 rows)

***(Single step mode: verify
command)*******************************************
GRANT ALL ON atest1 TO regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
GRANT SELECT ON atest1 TO regressuser3, regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
SELECT * FROM atest1;
***(press return to proceed or enter x and return to
cancel)********************

a | b
---+---
(0 rows)

***(Single step mode: verify
command)*******************************************
CREATE TABLE atest2 (col1 varchar(10), col2 boolean);
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:40: ERROR: relation "atest2" already exists
***(Single step mode: verify
command)*******************************************
GRANT SELECT ON atest2 TO regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
GRANT UPDATE ON atest2 TO regressuser3;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
GRANT INSERT ON atest2 TO regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
SELECT session_user, current_user;
***(press return to proceed or enter x and return to
cancel)********************

session_user | current_user
--------------+--------------
regressuser2 | regressuser2
(1 row)

***(Single step mode: verify
command)*******************************************
SELECT * FROM atest1;
***(press return to proceed or enter x and return to
cancel)********************

a | b
---+---
(0 rows)

***(Single step mode: verify
command)*******************************************
SELECT * FROM atest2;
***(press return to proceed or enter x and return to
cancel)********************

col1 | col2
------+------
bar | t
(1 row)

***(Single step mode: verify
command)*******************************************
INSERT INTO atest1 VALUES (2, 'two');
***(press return to proceed or enter x and return to
cancel)********************

INSERT 2356105 1
***(Single step mode: verify
command)*******************************************
INSERT INTO atest2 VALUES ('foo', true);
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:54: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
INSERT INTO atest1 SELECT 1, b FROM atest1;
***(press return to proceed or enter x and return to
cancel)********************

INSERT 2356106 1
***(Single step mode: verify
command)*******************************************
UPDATE atest1 SET a = 1 WHERE a = 2;
***(press return to proceed or enter x and return to
cancel)********************

UPDATE 1
***(Single step mode: verify
command)*******************************************
UPDATE atest2 SET col2 = NOT col2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:57: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
SELECT * FROM atest1 FOR UPDATE;
***(press return to proceed or enter x and return to
cancel)********************

a | b
---+-----
1 | two
1 | two
(2 rows)

***(Single step mode: verify
command)*******************************************
SELECT * FROM atest2 FOR UPDATE;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:59: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
DELETE FROM atest2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:60: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
LOCK atest2 IN ACCESS EXCLUSIVE MODE;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:61: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
COPY atest2 FROM stdin;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:62: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
GRANT ALL ON atest1 TO PUBLIC;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:63: ERROR: permission denied for relation atest1
***(Single step mode: verify
command)*******************************************
SELECT * FROM atest1 WHERE ( b IN ( SELECT col1 FROM atest2 ) );
***(press return to proceed or enter x and return to
cancel)********************

a | b
---+---
(0 rows)

***(Single step mode: verify
command)*******************************************
SELECT * FROM atest2 WHERE ( col1 IN ( SELECT b FROM atest1 ) );
***(press return to proceed or enter x and return to
cancel)********************

col1 | col2
------+------
(0 rows)

***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser3;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
SELECT session_user, current_user;
***(press return to proceed or enter x and return to
cancel)********************

session_user | current_user
--------------+--------------
regressuser3 | regressuser3
(1 row)

***(Single step mode: verify
command)*******************************************
SELECT * FROM atest1;
***(press return to proceed or enter x and return to
cancel)********************

a | b
---+-----
1 | two
1 | two
(2 rows)

***(Single step mode: verify
command)*******************************************
SELECT * FROM atest2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:74: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
INSERT INTO atest1 VALUES (2, 'two');
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:75: ERROR: permission denied for relation atest1
***(Single step mode: verify
command)*******************************************
INSERT INTO atest2 VALUES ('foo', true);
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:76: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
INSERT INTO atest1 SELECT 1, b FROM atest1;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:77: ERROR: permission denied for relation atest1
***(Single step mode: verify
command)*******************************************
UPDATE atest1 SET a = 1 WHERE a = 2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:78: ERROR: permission denied for relation atest1
***(Single step mode: verify
command)*******************************************
UPDATE atest2 SET col2 = NULL;
***(press return to proceed or enter x and return to
cancel)********************

UPDATE 1
***(Single step mode: verify
command)*******************************************
UPDATE atest2 SET col2 = NOT col2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:80: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
UPDATE atest2 SET col2 = true WHERE atest1.a = 5;
***(press return to proceed or enter x and return to
cancel)********************

UPDATE 0
***(Single step mode: verify
command)*******************************************
SELECT * FROM atest1 FOR UPDATE;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:82: ERROR: permission denied for relation atest1
***(Single step mode: verify
command)*******************************************
SELECT * FROM atest2 FOR UPDATE;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:83: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
DELETE FROM atest2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:84: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
LOCK atest2 IN ACCESS EXCLUSIVE MODE;
***(press return to proceed or enter x and return to
cancel)********************

LOCK TABLE
***(Single step mode: verify
command)*******************************************
COPY atest2 FROM stdin;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:86: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
SELECT * FROM atest1 WHERE ( b IN ( SELECT col1 FROM atest2 ) );
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:89: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
SELECT * FROM atest2 WHERE ( col1 IN ( SELECT b FROM atest1 ) );
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:90: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
COPY atest2 FROM stdin;
***(press return to proceed or enter x and return to
cancel)********************

***(Single step mode: verify
command)*******************************************
SELECT * FROM atest1;
***(press return to proceed or enter x and return to
cancel)********************

a | b
---+-----
1 | two
1 | two
(2 rows)

***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser3;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
CREATE TABLE atest3 (one int, two int, three int);
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:102: ERROR: relation "atest3" already exists
***(Single step mode: verify
command)*******************************************
GRANT DELETE ON atest3 TO GROUP regressgroup2;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser1;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
SELECT * FROM atest3;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:107: ERROR: permission denied for relation atest3
***(Single step mode: verify
command)*******************************************
DELETE FROM atest3;
***(press return to proceed or enter x and return to
cancel)********************

DELETE 0
***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser3;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
CREATE VIEW atestv1 AS SELECT * FROM atest1;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:115: ERROR: relation "atestv1" already exists
***(Single step mode: verify
command)*******************************************
/* The next *should* fail, but it's not implemented that way yet. */
CREATE VIEW atestv2 AS SELECT * FROM atest2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:117: ERROR: relation "atestv2" already exists
***(Single step mode: verify
command)*******************************************
CREATE VIEW atestv3 AS SELECT * FROM atest3;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:118: ERROR: relation "atestv3" already exists
***(Single step mode: verify
command)*******************************************
SELECT * FROM atestv1;
***(press return to proceed or enter x and return to
cancel)********************

a | b
---+-----
1 | two
1 | two
(2 rows)

***(Single step mode: verify
command)*******************************************
SELECT * FROM atestv2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:121: ERROR: permission denied for relation atest2
***(Single step mode: verify
command)*******************************************
GRANT SELECT ON atestv1, atestv3 TO regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
GRANT SELECT ON atestv2 TO regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
SELECT * FROM atestv1;
***(press return to proceed or enter x and return to
cancel)********************

a | b
---+-----
1 | two
1 | two
(2 rows)

***(Single step mode: verify
command)*******************************************
SELECT * FROM atestv2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:128: ERROR: permission denied for relation atestv2
***(Single step mode: verify
command)*******************************************
SELECT * FROM atestv3;
***(press return to proceed or enter x and return to
cancel)********************

one | two | three
-----+-----+-------
(0 rows)

***(Single step mode: verify
command)*******************************************
CREATE VIEW atestv4 AS SELECT * FROM atestv3;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:131: ERROR: relation "atestv4" already exists
***(Single step mode: verify
command)*******************************************
SELECT * FROM atestv4;
***(press return to proceed or enter x and return to
cancel)********************

one | two | three
-----+-----+-------
(0 rows)

***(Single step mode: verify
command)*******************************************
GRANT SELECT ON atestv4 TO regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
SELECT * FROM atestv3;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:139: ERROR: permission denied for relation atestv3
***(Single step mode: verify
command)*******************************************
SELECT * FROM atestv4;
***(press return to proceed or enter x and return to
cancel)********************

one | two | three
-----+-----+-------
(0 rows)

***(Single step mode: verify
command)*******************************************
SELECT * FROM atest2;
***(press return to proceed or enter x and return to
cancel)********************

col1 | col2
------+------
bar |
bar | t
(2 rows)

***(Single step mode: verify
command)*******************************************
SELECT * FROM atestv2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:143: ERROR: permission denied for relation atest2
You are now connected to database "regression".
***(Single step mode: verify
command)*******************************************
REVOKE ALL PRIVILEGES ON LANGUAGE sql FROM PUBLIC;
***(press return to proceed or enter x and return to
cancel)********************

REVOKE
***(Single step mode: verify
command)*******************************************
GRANT USAGE ON LANGUAGE sql TO regressuser1;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
GRANT USAGE ON LANGUAGE c TO PUBLIC;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:153: ERROR: language "c" is not trusted
***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser1;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
GRANT USAGE ON LANGUAGE sql TO regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:156: ERROR: permission denied for language sql
***(Single step mode: verify
command)*******************************************
CREATE FUNCTION testfunc1(int) RETURNS int AS 'select 2 * $1;' LANGUAGE sql;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:157: ERROR: function "testfunc1" already exists with
same argument types
***(Single step mode: verify
command)*******************************************
CREATE FUNCTION testfunc2(int) RETURNS int AS 'select 3 * $1;' LANGUAGE sql;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:158: ERROR: function "testfunc2" already exists with
same argument types
***(Single step mode: verify
command)*******************************************
REVOKE ALL ON FUNCTION testfunc1(int), testfunc2(int) FROM PUBLIC;
***(press return to proceed or enter x and return to
cancel)********************

REVOKE
***(Single step mode: verify
command)*******************************************
GRANT EXECUTE ON FUNCTION testfunc1(int), testfunc2(int) TO regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
GRANT USAGE ON FUNCTION testfunc1(int) TO regressuser3;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:162: ERROR: invalid privilege type USAGE for function
***(Single step mode: verify
command)*******************************************
GRANT ALL PRIVILEGES ON FUNCTION testfunc1(int) TO regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
GRANT ALL PRIVILEGES ON FUNCTION testfunc_nosuch(int) TO regressuser4;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:164: ERROR: function testfunc_nosuch(integer) does not
exist
***(Single step mode: verify
command)*******************************************
CREATE FUNCTION testfunc4(boolean) RETURNS text
AS 'select col1 from atest2 where col2 = $1;'
LANGUAGE sql SECURITY DEFINER;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:168: ERROR: function "testfunc4" already exists with
same argument types
***(Single step mode: verify
command)*******************************************
GRANT EXECUTE ON FUNCTION testfunc4(boolean) TO regressuser3;
***(press return to proceed or enter x and return to
cancel)********************

GRANT
***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser2;
***(press return to proceed or enter x and return to
cancel)********************

SET
***(Single step mode: verify
command)*******************************************
SELECT testfunc1(5), testfunc2(5);
***(press return to proceed or enter x and return to
cancel)********************

testfunc1 | testfunc2
-----------+-----------
10 | 15
(1 row)

***(Single step mode: verify
command)*******************************************
CREATE FUNCTION testfunc3(int) RETURNS int AS 'select 2 * $1;' LANGUAGE sql;
***(press return to proceed or enter x and return to
cancel)********************

psql:privileges.sql:173: ERROR: function "testfunc3" already exists with
same argument types
***(Single step mode: verify
command)*******************************************
SET SESSION AUTHORIZATION regressuser3;
***(press return to proceed or enter x and return to
cancel)********************
x
***(Single step mode: verify
command)*******************************************
SELECT testfunc1(5);
***(press return to proceed or enter x and return to
cancel)********************
regression=> select? ?? ?? ?? ?? ?? ????\?~d? ?? ?d? ?c regression ler
You are now connected to database "regression" as user "ler".
regression=# select * from pg_language;
***(Single step mode: verify
command)*******************************************
select * from pg_language;
***(press return to proceed or enter x and return to
cancel)********************

lanname | lanispl | lanpltrusted | lanplcallfoid | lanvalidator |
lanacl
----------+---------+--------------+---------------+--------------+--------
--------------------------
internal | f | f | 0 | 2246 |
c | f | f | 0 | 2247 |
plpgsql | t | t | 2218642 | 0 |
sql | f | t | 0 | 2248 |
{=U/postgres,regressuser1=U/ler}
(4 rows)

regression=# select * from pg_shadow;
***(Single step mode: verify
command)*******************************************
select * from pg_shadow;
***(press return to proceed or enter x and return to
cancel)********************

usename | usesysid | usecreatedb | usesuper | usecatupd |
passwd | valuntil | useconfig
--------------+----------+-------------+----------+-----------+------------
-------------------------+----------+-----------
horde | 407 | t | f | f |
md5789761213b76339cb1da715d0c51d888 | |
ler | 101 | t | t | t |
md5dc936a84fbec3cdca4209c15f1ce424d | |
mrm | 401 | t | f | f |
md59a6f9a2291c2b99dfa7794167f6f90e5 | |
cph | 151 | t | f | f |
md56f213a50183cb0b5b503391c96061751 | |
nobody | 403 | f | f | f |
md5eaa50fc990ef9147accb04fd39c69263 | |
ed | 402 | t | f | f |
md56d10f55bec241097be543d50441902a4 | |
webmail | 404 | t | f | f |
md5939853e11c511400d5709c547287a8a9 | |
tipnet | 405 | t | f | f |
md5ceba6024d54ca3d68647dae1cd58222a | |
nagios | 408 | f | f | f |
md5d36bbc9979deee7cca850e582b9a8e18 | |
webcal | 409 | f | f | f |
md5e736e686ce964baaa81ec18583f06921 | |
bric | 413 | f | f | f |
md55a71606fd33d3e92229ce73ad6c3f408 | |
ohp | 410 | t | f | f |
md59276c229c3c21fdc944a7532db499a01 | |
root | 411 | t | t | t |
md5a54504778e2f7c06d13e420bca278b16 | |
rt_user | 412 | f | f | f |
md5e5ffbd5626278386cfa50d801ce24517 | |
regressuser1 | 414 | f | f | f |
| |
postgres | 1 | t | t | t |
md51a4c61baf99fb9be1b8763c70f4304e7 | |
regressuser2 | 415 | f | f | f |
| |
regressuser3 | 416 | f | f | f |
| |
regressuser4 | 417 | f | f | f |
| |
(19 rows)

regression=# select *? ?current_user session_user;???????????????[1@,
***(Single step mode: verify
command)*******************************************
select current_user, session_user;
***(press return to proceed or enter x and return to
cancel)********************

current_user | session_user
--------------+--------------
ler | ler
(1 row)

regression=# \q
$

script done on Sat Oct 25 16:36:56 2003

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

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(at)candle(dot)pha(dot)pa(dot)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(at)postgresql(dot)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

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(at)sysexperts(dot)com

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

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(at)gmx(dot)net
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Ports list updated:

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

Again, I need help converting this name to SGML.

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

Hans-Jrgen Schnig wrote:
> Regression testing on AIX 5 using 7.4beta5:
>
>
> polymorphism ... ok
> stats ... ok
> ============== shutting down postmaster ==============
>
> ======================
> All 93 tests passed.
> ======================
>
>
> bash-2.05$ uname -a
> AIX sn2 1 5 0044276A4C00
>
>
> checking build system type... powerpc-ibm-aix5.1.0.0
> checking host system type... powerpc-ibm-aix5.1.0.0
> checking which template to use... aix
>
> bash-2.05$ gcc -v
> Reading specs from
> /usr/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix43-010414/specs
> gcc version 2.9-aix43-010414
>
> Good work :)
>
> Hans
>
> --
> Cybertec Geschwinde u Schoenig
> Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
> Tel: +43/2952/30706 or +43/660/816 40 77
> www.cybertec.at, www.postgresql.at, kernel.cybertec.at
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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
>

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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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;

======================================================================

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

Johan Henselmans <johan(at)netsense(dot)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

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

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(at)albourne(dot)com>
APL Financial Services (Overseas) Ltd

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(at)albourne(dot)com>
> APL Financial Services (Overseas) Ltd
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

Bruce Momjian writes:

> It is time for people to report their port testing. Please test against
> current CVS or beta5 and report your 'uname -a'.

For a change, here is one that does not work:

HP-UX hpunix5 B.11.00 U 9000/803 2002765023

Using the system compiler, I get several complaints about our use of
"inline", for example:

cc -Ae +O2 -I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -c -o dynahash.o dynahash.c
cc: "dynahash.c", line 466: error 1000: Unexpected symbol: "calc_bucket".
cc: panic 2017: Cannot recover from earlier errors, terminating.

I had to patch it as follows to get it to work:

diff -ur ../cvs-pgsql/src/backend/utils/hash/dynahash.c ./src/backend/utils/hash/dynahash.c
--- ../cvs-pgsql/src/backend/utils/hash/dynahash.c 2003-08-19 03:13:41.000000000 +0200
+++ ./src/backend/utils/hash/dynahash.c 2003-10-31 11:05:05.000000000 +0100
@@ -462,7 +462,7 @@

/* Convert a hash value to a bucket number */
-static inline uint32
+static uint32
calc_bucket(HASHHDR *hctl, uint32 hash_val)
{
uint32 bucket;
diff -ur ../cvs-pgsql/src/backend/utils/sort/tuplesort.c ./src/backend/utils/sort/tuplesort.c
--- ../cvs-pgsql/src/backend/utils/sort/tuplesort.c 2003-08-17 21:58:06.000000000 +0200
+++ ./src/backend/utils/sort/tuplesort.c 2003-10-31 11:10:12.000000000 +0100
@@ -1784,7 +1784,7 @@
/*
* Inline-able copy of FunctionCall2() to save some cycles in sorting.
*/
-static inline Datum
+static Datum
myFunctionCall2(FmgrInfo *flinfo, Datum arg1, Datum arg2)
{
FunctionCallInfoData fcinfo;
@@ -1816,7 +1816,7 @@
* and return a 3-way comparison result. This takes care of handling
* NULLs and sort ordering direction properly.
*/
-static inline int32
+static int32
inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
Datum datum1, bool isNull1,
Datum datum2, bool isNull2)

Any ideas?

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut <peter_e(at)gmx(dot)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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)zip(dot)com(dot)au>

* lib/autoconf/c.m4 (AC_C_INLINE): Test with a typedef return value,
to avoid versions of HP C which don't allow that.

So there you have it. Do we want to backpatch the new autoconf test, or
define inline to empty for this particular version of this platform, or
try to do without typedef'd types? I prefer option 1.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut <peter_e(at)gmx(dot)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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)net

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(at)gmx(dot)net

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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