This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: [HACKERS] RPMS for 7.0 final.
From: Lamar Owen <lamar.owen@wgcr.org>
Date: Mon, 15 May 2000 22:52:42 -0400
Announcing RedHat RPMs for PostgreSQL 7.0
NEW LOCATION!
ftp://ftp.postgresql.org/pub/binary/v7.0/redhat-RPM
Please read the README in that directory before downloading. That same
file is installed as part of the postgresql-7.0-1.i386.rpm as
/usr/doc/postgresql-7.0/README.rpm.
Or, you may go to http://www.ramifordistat.net/postgres as usual.
**********NOTE***********
An initdb is REQUIRED for an upgrade from prior to Postgresql-7.0RC5.
--oldpackage may be required to upgrade from 7.0 beta releases or
release candidate RPMS.
Please let me know about any problems you may have.
My apologies for the delay in getting this RPM out -- my 'Real World'
work schedule drastically interferred with my PostgreSQL schedule, and
will continue to do so until at least May 24th. For the curious, I am a
broadcast engineer, and am in the middle of a transmitter site move.
NOTE: There are no Linux/alpha patches in these RPMs. Hopefully, that
situation will soon be rectified in a -2 RPMset. However, I _did_ get
the 7.0 JDBC jar's in....
Hope you enjoy the RPMs!
===
Subject: Re: [HACKERS] RPMS for 7.0 final.
From: Lamar Owen <lamar.owen@wgcr.org>
Date: Tue, 16 May 2000 08:17:59 -0400
Peter Mount wrote:
>Lamar Owen Wrote:
>> NOTE: There are no Linux/alpha patches in these RPMs. Hopefully, that
>> situation will soon be rectified in a -2 RPMset. However, I _did_ get
>> the 7.0 JDBC jar's in....
> PM: Good job I got them done in time wasn't it ;-)
The interesting side of it was that I had already built the RPM's,
realized that I had forgotten a changelog note in the spec file, and
happened to check mail -- and you had just announced the jars. I was
quite happy to see _that_ announcement! I was not a happy camper that I
wasn't going to have 7.0 jars, and didn't have the time nor the presence
of mind to install the jdk and build them myself. I triple-checked the
RPM stuff, so, hopefully, there won't be any stupid errors there -- as I
pretty well know that part of things -- but, java I know not. But, happy
camper I now am!
===
Subject: [HACKERS] 7.0 RPMS and syslog problem.
From: Michael Schout <mschout@gkg.net>
Date: Wed, 17 May 2000 09:26:05 -0500
Hi.
I've installed the v7.0 postgresql RPMS from ftp.postgresql.org. I configured
my syslog to catch the local0 facility and log it to /var/log/pgsql with this
entry in /etc/syslog.conf:
local0.* /var/log/pgsql
This catches just about everything. However, if I fire up "psql template1" and
issue the command "\d", the following is broadcast to all tty's on the machine:
Message from syslogd@galaxy at Wed May 17 09:20:12 2000 ...
galaxy
My guess is that something is not logging to the correct facility. Has anyone
else seen this / found a work around for this?
my pg_options file contains:
verbose=1
query=4
syslog=2
===
Subject: Re: [HACKERS] 7.0 RPMS and syslog problem. (more)
From: Michael Schout <mschout@gkg.net>
Date: Wed, 17 May 2000 09:44:53 -0500
Upon further investigation, I found that when the hostname is broadcast to everyone, the following also appears in /var/log/messages:
May 17 09:28:11 galaxy
May 17 09:28:11 galaxy syslogd: Cannot glue message parts together
May 17 09:28:11 galaxy 135>May 17 09:28:11 postgres[18087]: query: SELECT c.relname as "Name", 'table'::text as "Type", u.usename as "Owner" FROM pg_class c, pg_user u WHERE c.relowner = u.usesysid AND c.relkind = 'r' AND not exists (select 1 from pg_views where viewname = c.relname) AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name", 'table'::text as "Type", NULL as "Owner" FROM pg_class c WHERE c.relkind = 'r' AND not exists (select 1 from pg_views where viewname = c.relname) AND not exists (select 1 from pg_user where usesysid = c.relowner) AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name", 'view'::text as "Type", u.usename as "Owner" FROM pg_class c, pg_user u WHERE c.relowner = u.usesysid AND c.relkind = 'r' AND exists (select 1 from pg_views where viewname = c.relname) AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name", 'view'::text as "Type", NULL as "Owner" FROM pg_class c WHERE c.relkind = 'r' AND exists (select 1 from pg_views w!
he!
re viewname = c.relname) AND not exists (select 1 fro
May 17 09:28:11 galaxy m pg_user where usesysid = c.relowner) AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name", (CASE WHEN relkind = 'S' THEN 'sequence'::text ELSE 'index'::text END) as "Type", u.usename as "Owner" FROM pg_class c, pg_user u WHERE c.relowner = u.usesysid AND relkind in ('S') AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name", (CASE WHEN relkind = 'S' THEN 'sequence'::text ELSE 'index'::text END) as "Type", NULL as "Owner" FROM pg_class c WHERE not exists (select 1 from pg_user where usesysid = c.relowner) AND relkind in ('S') AND c.relname !~ '^pg_' ORDER BY "Name"
So the problem seems to stem from the "Cannot glue message parts together"
The hostname is being broadcast to with the level of "emerg" because if I
remove:
*.emerg *
from my syslog.conf file, I dont see the console message getting broadcast
anymore.
If anyone else has seen this or has any ideas, please let me know :).
===
Subject: Re: [HACKERS] 7.0 RPMS and syslog problem. (more)
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 17 May 2000 11:59:15 -0400
Michael Schout <mschout@gkg.net> writes:
> Upon further investigation, I found that when the hostname is broadcast to everyone, the following also appears in /var/log/messages:
> May 17 09:28:11 galaxy
> May 17 09:28:11 galaxy syslogd: Cannot glue message parts together
Hmm. We were just discussing this a few weeks ago, when someone
suggested making the syslog option be the default and I wanted to
know if it was really robust enough for that. Seems it's not.
On at least some platforms, syslog can't cope with log messages
exceeding a few hundred characters. Postgres 7.0 is quite capable
of putting out log messages in the megabyte range, if you have debug
logging turned on --- just shove a sufficiently long query at it.
So I'm afraid the answer is that syslog and verbose logging won't
play together, at least not on your platform. Sorry.
We really need a better logging answer...
===
Subject: Re: [HACKERS] 7.0 RPMS and syslog problem. (more)
From: Lamar Owen <lamar.owen@wgcr.org>
Date: Wed, 17 May 2000 12:55:59 -0400
Tom Lane wrote:
> Michael Schout <mschout@gkg.net> writes:
> > Upon further investigation, I found that when the hostname is broadcast to everyone, the following also appears in /var/log/messages:
> > May 17 09:28:11 galaxy
> > May 17 09:28:11 galaxy syslogd: Cannot glue message parts together
> Hmm. We were just discussing this a few weeks ago, when someone
> suggested making the syslog option be the default and I wanted to
> know if it was really robust enough for that. Seems it's not.
> So I'm afraid the answer is that syslog and verbose logging won't
> play together, at least not on your platform. Sorry.
> We really need a better logging answer...
Splitting the logging message out to syslog in tprintf() (or its
replacement) would work, if we knew the syslog gluing buffer maxlen. A
'packetized' logging system of this sort might work....
===
Subject: Re: [HACKERS] 7.0 RPMS and syslog problem. (more)
From: Michael Schout <mschout@gkg.net>
Date: Wed, 17 May 2000 17:52:14 -0500
On Wed, May 17, 2000 at 11:59:15AM -0400, Tom Lane wrote:
> Michael Schout <mschout@gkg.net> writes:
>
> Hmm. We were just discussing this a few weeks ago, when someone
> suggested making the syslog option be the default and I wanted to
> know if it was really robust enough for that. Seems it's not.
Perhaps the maintainer of the binary RPMS on ftp.postgresql.org
could rebuild with syslog logging turned off by default?
===
Subject: Re: [HACKERS] 7.0 RPMS and syslog problem. (more)
From: Lamar Owen <lamar.owen@wgcr.org>
Date: Wed, 17 May 2000 23:37:10 -0400
Michael Schout wrote:
> On Wed, May 17, 2000 at 11:59:15AM -0400, Tom Lane wrote:
> > Hmm. We were just discussing this a few weeks ago, when someone
> > suggested making the syslog option be the default and I wanted to
> > know if it was really robust enough for that. Seems it's not.
> Perhaps the maintainer of the binary RPMS on ftp.postgresql.org
> could rebuild with syslog logging turned off by default?
Set the pg_options -- ie, set syslog to 0, or set query to 0, if you
don't need query logging. There's no need to recompile, as the runtime
option sets things properly. I would prefer to not disable syslog when
it is working fine for those who have shorter queries. I will, however,
change the default pg_options with syslog set to 0 -- same effect, but
it still allows those with less difficult query-length requirements to
use the feature -- with the caveat that too long a query with query
logging on will crash out syslog.
So, I have two notices to add to the ramifordistat page, and to the
README.rpm..... I won't build a -2 release as yet, until we get the
actual query length of overflow (volunteers?) so that it can be
documented.
If you want to completely disable syslog on your own RPMS, feel free to
download the src.rpm, edit rpm-pgsql-7.0.patch to remove the USE_SYSLOG
define, and rebuild with rpm -ba. Then install the resulting RPMs. If
you wouldn't mind, change the release number so that no one gets
confused.
===
Subject: [ANNOUNCE] PostgreSQL 7.0 a success
From: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Sat, 20 May 2000 23:20:42 -0400 (EDT)
PostgreSQL 7.0 has been a huge success. Bug reports since release have
been so few that we thought our e-mail system wasn't working properly.
Turns out things are very quiet because the release is so stable.
So, those people waiting on the fence to try 7.0, go ahead. It is
ready for prime-time.
Of course, we have big plans for 7.1, and will start on that shortly.
===
Subject: [HACKERS] port v7.0 to SGI-IRIX-6.5.7/64
From: Murad Nayal <murad@godel.bioc.columbia.edu>
Date: Mon, 22 May 2000 18:42:48 +0200
I managed to compile (and sort of run) postgres 7.0 to SGI running IRIX
6.5.7. I compiled to 64bit libraries. The problems I had were both due
errors in the configure script as well as postgres configuration files.
configure problems:
-------------------
1- the program that configure uses to test for namespace std is faulty.
I had to manually add #define HAVE_NAMESPACE_STD 1 to the top of
interfaces/libpq++/pgconnection.h
2- configure badly guesses the type of the 3rd argument to accept(). it
decided it should be size_t (unsigned int on IRIX) while accept on IRIX
takes an int. postgres compiles, but accept never retrieves the IP
address of the connecting client (in StreamConnection() function in the
file backend/libpq/pqcomm.c). as a result no authentication can happen
and the postmaster refuses connections regardless of what is in
pg_hba.conf. the error message is usually something like
"no pg_hba.conf entry for host localhost user postgres database
template1"
here local host is just a default string and apparently will never match
anything in pg_hba.conf. to fix this i changed line 521 of
include/config.h
from: #define SOCKET_SIZE_TYPE size_t
to: #define SOCKET_SIZE_TYPE int
postgres problems
------------------
3- src/pl/tcl/Makefile has a bug. line 69 is
CFLAGS= $(TCL_CFLAGS_OPTIMIZE)
that clobbers all CFLAGS included previously. as a result the include
directories, important to find tcl.h etc. will not be added to the
options and the compilation stops here complaining that it can't locate
tcl.h etc.
I just changed it to
CFLAGS+= $(TCL_CFLAGS_OPTIMIZE)
4- I had to change line 8 of interfaces/odbc/isqlext.h
from # include <isql.h>
to # include "isql.h"
to force the inclusion of the local isql.h
now my questions: While compiling, i noticed a lot of warnings about
pointers getting truncated etc. it seems that postgres assumes pointer
sizes to be 32 bits. so I suppose compiling for a 64bit platform can be
risky. Anyone have experience compiling postgres on a 64bit platform.
a lot of the regression tests also failed. some of these failures don't
seem to be trivial (some are trivial). I will paste below the overall
report of the regression testing. But what I would really love is for
someone to look at the my regression.diffs and kind of enlighten me to
the problems I should expect with this installation or (better still)
what to look at to fix the problems. I have not used postgres before and
am actually fairly green with databases in general so any help is most
appreciated.
if interested I could email you the diffs for the above changes.
Best Regards
Murad Nayal
configure command
-----------------
./configure --prefix=/local --with-includes=/local/include
--with-libraries=/local/lib --with-tcl --with-tclconfig=/local/lib
--with-tkconfig=/local/lib --with-perl --with-odbc --with-CC="cc -O2
-Xcpluscomm" --with-CXX="CC -O2" --with-x
regression results
------------------
gmake runtest
cc -O2 -Xcpluscomm -I../../include -I../../backend -I/local/include
-U_NO_XOPEN4 -woff 1164,1171,1185,1195,1552 -Wl,-woff,15 -Wl,-woff,84
-I../../interfaces/libpq -I../../include -c regress.c -o regress.o
ld -G -Bdynamic -shared -o regress.so regress.o
MULTIBYTE=;export MULTIBYTE; \
/bin/sh ./regress.sh mips-sgi-irix6.5 2>&1 | tee regress.out
=============== Notes... =================
postmaster must already be running for the regression tests to succeed.
The time zone is set to PST8PDT for these tests by the client frontend.
Please report any apparent problems to ports@postgresql.org
See regress/README for more information.
=============== dropping old regression database... =================
DROP DATABASE
=============== creating new regression database... =================
CREATE DATABASE
=============== installing languages... =================
installing PL/pgSQL .. ok
=============== running regression queries... =================
boolean .. ok
char .. ok
name .. ok
varchar .. ok
text .. ok
int2 .. failed
int4 .. failed
int8 .. failed
oid .. ok
float4 .. ok
float8 .. ok
numeric .. ok
strings .. failed
numerology .. failed
point .. ok
lseg .. ok
box .. ok
path .. ok
polygon .. ok
circle .. ok
interval .. ok
timestamp .. ok
reltime .. ok
tinterval .. failed
inet .. ok
comments .. ok
oidjoins .. failed
type_sanity .. failed
opr_sanity .. failed
abstime .. failed
geometry .. failed
horology .. failed
create_function_1 .. ./regress.sh[116]: sql/create_function_1.sql:
cannot open: No such file or directory
diff: expected/create_function_1.out: No such file or directory
diff: results/create_function_1.out: No such file or directory
ok
create_type .. failed
create_table .. ok
create_function_2 .. ./regress.sh[116]: sql/create_function_2.sql:
cannot open: No such file or directory
diff: expected/create_function_2.out: No such file or directory
diff: results/create_function_2.out: No such file or directory
ok
copy .. ./regress.sh[116]: sql/copy.sql: cannot open: No such file or
directory
diff: expected/copy.out: No such file or directory
diff: results/copy.out: No such file or directory
ok
constraints .. ./regress.sh[116]: sql/constraints.sql: cannot open: No
such file or directory
diff: expected/constraints.out: No such file or directory
diff: results/constraints.out: No such file or directory
ok
triggers .. failed
create_misc .. ok
create_aggregate .. ok
create_operator .. failed
create_index .. failed
create_view .. failed
sanity_check .. ok
errors .. ok
select .. failed
select_into .. ok
select_distinct .. failed
select_distinct_on .. failed
select_implicit .. ok
select_having .. ok
subselect .. ok
union .. ok
case .. ok
join .. ok
aggregates .. failed
transactions .. failed
random .. failed
portals .. failed
arrays .. ok
btree_index .. failed
hash_index .. failed
misc .. ./regress.sh[116]: sql/misc.sql: cannot open: No such file or
directory
diff: expected/misc.out: No such file or directory
diff: results/misc.out: No such file or directory
ok
select_views .. failed
alter_table .. failed
portals_p2 .. failed
rules .. failed
foreign_key .. ok
limit .. failed
plpgsql .. ok
temp .. ok
ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out
To run the optional big test(s) too, type 'make bigtest'
These big tests can take over an hour to complete
These actually are: numeric_big
rm regress.o
===
Subject: [PORTS] port v7.0 to SGI-IRIX-6.5.7/64
From: Murad Nayal <murad@godel.bioc.columbia.edu>
Date: Mon, 22 May 2000 18:42:48 +0200
I managed to compile (and sort of run) postgres 7.0 to SGI running IRIX
6.5.7. I compiled to 64bit libraries. The problems I had were both due
errors in the configure script as well as postgres configuration files.
configure problems:
-------------------
1- the program that configure uses to test for namespace std is faulty.
I had to manually add #define HAVE_NAMESPACE_STD 1 to the top of
interfaces/libpq++/pgconnection.h
2- configure badly guesses the type of the 3rd argument to accept(). it
decided it should be size_t (unsigned int on IRIX) while accept on IRIX
takes an int. postgres compiles, but accept never retrieves the IP
address of the connecting client (in StreamConnection() function in the
file backend/libpq/pqcomm.c). as a result no authentication can happen
and the postmaster refuses connections regardless of what is in
pg_hba.conf. the error message is usually something like
"no pg_hba.conf entry for host localhost user postgres database
template1"
here local host is just a default string and apparently will never match
anything in pg_hba.conf. to fix this i changed line 521 of
include/config.h
from: #define SOCKET_SIZE_TYPE size_t
to: #define SOCKET_SIZE_TYPE int
postgres problems
------------------
3- src/pl/tcl/Makefile has a bug. line 69 is
CFLAGS= $(TCL_CFLAGS_OPTIMIZE)
that clobbers all CFLAGS included previously. as a result the include
directories, important to find tcl.h etc. will not be added to the
options and the compilation stops here complaining that it can't locate
tcl.h etc.
I just changed it to
CFLAGS+= $(TCL_CFLAGS_OPTIMIZE)
4- I had to change line 8 of interfaces/odbc/isqlext.h
from # include <isql.h>
to # include "isql.h"
to force the inclusion of the local isql.h
now my questions: While compiling, i noticed a lot of warnings about
pointers getting truncated etc. it seems that postgres assumes pointer
sizes to be 32 bits. so I suppose compiling for a 64bit platform can be
risky. Anyone have experience compiling postgres on a 64bit platform.
a lot of the regression tests also failed. some of these failures don't
seem to be trivial (some are trivial). I will paste below the overall
report of the regression testing. But what I would really love is for
someone to look at the my regression.diffs and kind of enlighten me to
the problems I should expect with this installation or (better still)
what to look at to fix the problems. I have not used postgres before and
am actually fairly green with databases in general so any help is most
appreciated.
if interested I could email you the diffs for the above changes.
Best Regards
Murad Nayal
configure command
-----------------
./configure --prefix=/local --with-includes=/local/include
--with-libraries=/local/lib --with-tcl --with-tclconfig=/local/lib
--with-tkconfig=/local/lib --with-perl --with-odbc --with-CC="cc -O2
-Xcpluscomm" --with-CXX="CC -O2" --with-x
regression results
------------------
gmake runtest
cc -O2 -Xcpluscomm -I../../include -I../../backend -I/local/include
-U_NO_XOPEN4 -woff 1164,1171,1185,1195,1552 -Wl,-woff,15 -Wl,-woff,84
-I../../interfaces/libpq -I../../include -c regress.c -o regress.o
ld -G -Bdynamic -shared -o regress.so regress.o
MULTIBYTE=;export MULTIBYTE; \
/bin/sh ./regress.sh mips-sgi-irix6.5 2>&1 | tee regress.out
=============== Notes... =================
postmaster must already be running for the regression tests to succeed.
The time zone is set to PST8PDT for these tests by the client frontend.
Please report any apparent problems to ports@postgresql.org
See regress/README for more information.
=============== dropping old regression database... =================
DROP DATABASE
=============== creating new regression database... =================
CREATE DATABASE
=============== installing languages... =================
installing PL/pgSQL .. ok
=============== running regression queries... =================
boolean .. ok
char .. ok
name .. ok
varchar .. ok
text .. ok
int2 .. failed
int4 .. failed
int8 .. failed
oid .. ok
float4 .. ok
float8 .. ok
numeric .. ok
strings .. failed
numerology .. failed
point .. ok
lseg .. ok
box .. ok
path .. ok
polygon .. ok
circle .. ok
interval .. ok
timestamp .. ok
reltime .. ok
tinterval .. failed
inet .. ok
comments .. ok
oidjoins .. failed
type_sanity .. failed
opr_sanity .. failed
abstime .. failed
geometry .. failed
horology .. failed
create_function_1 .. ./regress.sh[116]: sql/create_function_1.sql:
cannot open: No such file or directory
diff: expected/create_function_1.out: No such file or directory
diff: results/create_function_1.out: No such file or directory
ok
create_type .. failed
create_table .. ok
create_function_2 .. ./regress.sh[116]: sql/create_function_2.sql:
cannot open: No such file or directory
diff: expected/create_function_2.out: No such file or directory
diff: results/create_function_2.out: No such file or directory
ok
copy .. ./regress.sh[116]: sql/copy.sql: cannot open: No such file or
directory
diff: expected/copy.out: No such file or directory
diff: results/copy.out: No such file or directory
ok
constraints .. ./regress.sh[116]: sql/constraints.sql: cannot open: No
such file or directory
diff: expected/constraints.out: No such file or directory
diff: results/constraints.out: No such file or directory
ok
triggers .. failed
create_misc .. ok
create_aggregate .. ok
create_operator .. failed
create_index .. failed
create_view .. failed
sanity_check .. ok
errors .. ok
select .. failed
select_into .. ok
select_distinct .. failed
select_distinct_on .. failed
select_implicit .. ok
select_having .. ok
subselect .. ok
union .. ok
case .. ok
join .. ok
aggregates .. failed
transactions .. failed
random .. failed
portals .. failed
arrays .. ok
btree_index .. failed
hash_index .. failed
misc .. ./regress.sh[116]: sql/misc.sql: cannot open: No such file or
directory
diff: expected/misc.out: No such file or directory
diff: results/misc.out: No such file or directory
ok
select_views .. failed
alter_table .. failed
portals_p2 .. failed
rules .. failed
foreign_key .. ok
limit .. failed
plpgsql .. ok
temp .. ok
ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out
To run the optional big test(s) too, type 'make bigtest'
These big tests can take over an hour to complete
These actually are: numeric_big
rm regress.o
===
Subject: [PORTS] Re: [BUGS] port v7.0 to SGI-IRIX-6.5.7/64
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 22 May 2000 19:35:46 -0400
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> 1- the program that configure uses to test for namespace std is faulty.
That's not very helpful :-( --- what's wrong with it?
> 2- configure badly guesses the type of the 3rd argument to accept().
I have seen that happen on other platforms too; not clear how to fix it.
But as long as the guessed value is the right size it should work,
I would think --- unsigned int vs. int shouldn't make a difference.
Are you sure that that is the reason it wasn't working?
> 3- src/pl/tcl/Makefile has a bug. line 69 is
> CFLAGS= $(TCL_CFLAGS_OPTIMIZE)
> that clobbers all CFLAGS included previously. as a result the include
> directories, important to find tcl.h etc. will not be added to the
> options and the compilation stops here complaining that it can't locate
> tcl.h etc.
> I just changed it to
> CFLAGS+= $(TCL_CFLAGS_OPTIMIZE)
Good point, but that's no solution --- the reason that the makefile
isn't keeping the main CFLAGS is that Tcl (and hence pltcl) may be
built with a different compiler than Postgres is being built with.
The Tcl compiler may not like the other compiler's switches. I guess
we could arrange to insert just the -I switches from your
--with-includes configuration command, however.
> 4- I had to change line 8 of interfaces/odbc/isqlext.h
> from # include <isql.h>
> to # include "isql.h"
> to force the inclusion of the local isql.h
Good catch.
> now my questions: While compiling, i noticed a lot of warnings about
> pointers getting truncated etc. it seems that postgres assumes pointer
> sizes to be 32 bits. so I suppose compiling for a 64bit platform can be
> risky. Anyone have experience compiling postgres on a 64bit platform.
We do assume that "unsigned long" will hold a pointer; if that's not
true on IRIX then you're going to have troubles. There are a number
of patches known to be needed on Alphas, which are planned for
integration into the standard distribution for 7.1 --- dunno if any
of them would help on your setup.
> a lot of the regression tests also failed. some of these failures don't
> seem to be trivial (some are trivial).
It looks like you neglected to run "make all" before "make runtest".
Try that and see if it gets better...
===
Subject: Re: [PORTS] Re: [BUGS] port v7.0 to SGI-IRIX-6.5.7/64
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 22 May 2000 20:58:57 -0400
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Good point, but that's no solution --- the reason that the makefile
>> isn't keeping the main CFLAGS is that Tcl (and hence pltcl) may be
>> built with a different compiler than Postgres is being built with.
>> The Tcl compiler may not like the other compiler's switches. I guess
>> we could arrange to insert just the -I switches from your
>> --with-includes configuration command, however.
> Tom, do you want his verion in Makefile, or the original?
I'm working on it now --- need to fix configure to export a list of
just the -I switches, so we can include those into the pltcl build.
plperl may have the same problem, haven't looked yet.
There is a potential problem in this area that I've actually seen
happen, but don't know a way around: the two compilers may have
different default search paths. For example, on my system gcc includes
/usr/local/include in its default search path, but the system cc does
not. So, if you've built Tcl with system cc, and installed it in
/usr/local, and then try to build Postgres with gcc and --with-tcl,
everything goes fine until you get to pltcl, whereupon it falls over
because pltcl will be built with cc and cc doesn't find tcl.h.
That will still happen with this fix. The only way to build that
configuration successfully is to explicitly say
"--with-includes=/usr/local/include --with-libs=/usr/local/lib".
Arguably this is a bug in Tcl's tclConfig.sh, since it probably ought to
put "-I/usr/local/include" into its own CFLAGS settings when it's been
built that way ... but it doesn't ...
I don't have an answer to solving that problem automatically,
but I thought it'd be good to mention it for the archives.
===
Subject: [PORTS] Re: [BUGS] port v7.0 to SGI-IRIX-6.5.7/64
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 22 May 2000 21:11:25 -0400
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> 2- configure badly guesses the type of the 3rd argument to accept(). it
>> decided it should be size_t (unsigned int on IRIX) while accept on IRIX
>> takes an int.
> Again, a suggested change?
This is something that's been bugging me for a while; the problem on
most platforms is that int vs unsigned int parameter will only draw a
warning from the compiler, and autoconf's TRY_COMPILE macro is only able
to detect outright errors.
I looked at the standard Autoconf macros just now, and found an example
that may give us the right solution: instead of trying to see whether
a call of accept with "int" or "unsigned int" parameter works, include
<sys/socket.h> and then write an "extern" declaration for accept with
the parameters we think it should have. This relies on the hope that
if the compiler sees two declarations for accept with different
parameter lists, it'll generate an error and not just a warning.
It seems like that should work at least as well, maybe better, as what
we're doing now --- but it's not the kind of change that I want to shove
into 7.0.1 with no beta testing! Probably we should introduce it early
in the 7.1 cycle instead, and see if anyone reports problems.
===
Subject: [HACKERS] Re: [BUGS] port v7.0 to SGI-IRIX-6.5.7/64
From: Murad Nayal <murad@godel.bioc.columbia.edu>
Date: Mon, 22 May 2000 22:53:07 +0200
Bruce Momjian wrote:
>
> >
> > I managed to compile (and sort of run) postgres 7.0 to SGI running IRIX
> > 6.5.7. I compiled to 64bit libraries. The problems I had were both due
> > errors in the configure script as well as postgres configuration files.
> >
> > configure problems:
> > -------------------
> > 1- the program that configure uses to test for namespace std is faulty.
> > I had to manually add #define HAVE_NAMESPACE_STD 1 to the top of
> > interfaces/libpq++/pgconnection.h
>
> Can you suggest a test that does work on Irix?
>
the current test is:
#line 1680 "configure"
#include "confdefs.h"
#include <stdio.h>
#include <stdlib.h>
using namespace std;
int main() {
; return 0; }
it fails with the message:
"configure", line 1683: error(3173): name must be a namespace name
using namespace std;
you just need to add a header file that contains elements of the C++
standard library defined in std. not all C++ standard library that comes
with the SGI C++ compiler are in defined in std. for example iostream
stuff are not in std. however string is. so just include the string
header file in the program. This compiles fine with CC:
#line 1680 "configure"
#include "confdefs.h"
#include <stdio.h>
#include <stdlib.h>
#include <string>
using namespace std;
int main() {
; return 0; }
the SGI compiler puts the std library in header files that don't end in
".h". same header file ending in ".h" will have declarations in the
global name space.
===
Subject: [PORTS] Re: [BUGS] port v7.0 to SGI-IRIX-6.5.7/64
From: Murad Nayal <murad@godel.bioc.columbia.edu>
Date: Mon, 22 May 2000 23:12:51 +0200
Tom Lane wrote:
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> 2- configure badly guesses the type of the 3rd argument to accept(). it
> >> decided it should be size_t (unsigned int on IRIX) while accept on IRIX
> >> takes an int.
>
> > Again, a suggested change?
>
> This is something that's been bugging me for a while; the problem on
> most platforms is that int vs unsigned int parameter will only draw a
> warning from the compiler, and autoconf's TRY_COMPILE macro is only able
> to detect outright errors.
>
> I looked at the standard Autoconf macros just now, and found an example
> that may give us the right solution: instead of trying to see whether
> a call of accept with "int" or "unsigned int" parameter works, include
> <sys/socket.h> and then write an "extern" declaration for accept with
> the parameters we think it should have. This relies on the hope that
> if the compiler sees two declarations for accept with different
> parameter lists, it'll generate an error and not just a warning.
sys/socket is already included in the test program. and yet all I get
from the cc compiler is a warning!!! But here is a bit of trivia that I
found. the CC compiler (C++ on SGI) won't take it and will generate an
error. I am not sure obviously if this is to be expected of other C++
compilers. This particular warning message on my compiler has the number
1164. you can turn warning messages to error conditions using the flag
-diag_error message_number. So while cc conftest.c in this case
generates a warning. cc -diag_error 1164 conftest.c will generate an
error. Again I don't know if this feature is common in other compilers.
===
Subject: [HACKERS] Re: [BUGS] port v7.0 to SGI-IRIX-6.5.7/64
From: Murad Nayal <murad@godel.bioc.columbia.edu>
Date: Mon, 22 May 2000 23:12:51 +0200
Tom Lane wrote:
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> 2- configure badly guesses the type of the 3rd argument to accept(). it
> >> decided it should be size_t (unsigned int on IRIX) while accept on IRIX
> >> takes an int.
>
> > Again, a suggested change?
>
> This is something that's been bugging me for a while; the problem on
> most platforms is that int vs unsigned int parameter will only draw a
> warning from the compiler, and autoconf's TRY_COMPILE macro is only able
> to detect outright errors.
>
> I looked at the standard Autoconf macros just now, and found an example
> that may give us the right solution: instead of trying to see whether
> a call of accept with "int" or "unsigned int" parameter works, include
> <sys/socket.h> and then write an "extern" declaration for accept with
> the parameters we think it should have. This relies on the hope that
> if the compiler sees two declarations for accept with different
> parameter lists, it'll generate an error and not just a warning.
sys/socket is already included in the test program. and yet all I get
from the cc compiler is a warning!!! But here is a bit of trivia that I
found. the CC compiler (C++ on SGI) won't take it and will generate an
error. I am not sure obviously if this is to be expected of other C++
compilers. This particular warning message on my compiler has the number
1164. you can turn warning messages to error conditions using the flag
-diag_error message_number. So while cc conftest.c in this case
generates a warning. cc -diag_error 1164 conftest.c will generate an
error. Again I don't know if this feature is common in other compilers.
===
Subject: [PORTS] Re: [BUGS] port v7.0 to SGI-IRIX-6.5.7/64
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 22 May 2000 23:59:42 -0400
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> I was a little bit inaccurate in my
> statement earlier though. size_t is unsigned int when compiling in 32bit
> mode. however it seems to be unsigned long (8 bytes) when compiling in
> 64bit mode, while int is still 4 bytes.
OK, in that case I'd believe it's a critical issue.
I think the conflicting-declarations trick I mentioned earlier will let
us build a more reliable configure test for this, but as I said I don't
want to risk shoving it into 7.0.* --- this is the sort of thing that
you can't trust until it's been through some beta testing on a variety
of platforms. We'll put it in 7.1 and see what happens. In the
meantime you'll have to patch config.h by hand...
===
Subject: [PORTS] Re: [BUGS] port v7.0 to SGI-IRIX-6.5.7/64
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 23 May 2000 00:02:57 -0400
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> you just need to add a header file that contains elements of the C++
> standard library defined in std. not all C++ standard library that comes
> with the SGI C++ compiler are in defined in std. for example iostream
> stuff are not in std. however string is. so just include the string
> header file in the program.
You realize, of course, that we don't want to depend on <string>
being there either ;-)
But I suppose we could swap the order of the tests, and then
include <string> into the namespace test if we've found it.
Will do...
===
Subject: Re: [HACKERS] Regression test failure on 7.0-STABLE
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 28 May 2000 01:36:04 -0400
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> I saw some errors on the regression test, and they are new to me.
> Here are the output from checkresults.
> ====== rules ======
> 1168d1167
> < pg_indexes | SELECT c.relname AS tablename, i.relname AS indexname, pg_get_indexdef(x.indexrelid) AS indexdef FROM pg_index x, pg_class c, pg_class i WHERE ((c.oid = x.indrelid) AND (i.oid = x.indexrelid));
> 1187c1186
> < (20 rows)
> ---
>> (19 rows)
> ====== foreign_key ======
> 11a12
>> NOTICE: _outNode: don't know how to print type 726
> 235a237
>> NOTICE: _outNode: don't know how to print type 726
> I guess the error on foreign_key is caused by -d 3 turned on(does this
> hurt anything?) But what about the rules?
The NOTICEs are caused by a known omission: the foreign-key boys didn't
bother to add an outfuncs.c routine for node type FkConstraint. Should
be pretty harmless AFAIK. The rules discrepancy is much more
disturbing. Is it repeatable?
===
Subject: Re: [HACKERS] Regression test failure on 7.0-STABLE
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Sun, 28 May 2000 14:30:30 +0900
Oops.
> I saw some errors on the regression test, and they are new to me.
> Here are the output from checkresults.
>
> ====== rules ======
> 1168d1167
> < pg_indexes | SELECT c.relname AS tablename, i.relname AS indexname, pg_get_indexdef(x.indexrelid) AS indexdef FROM pg_index x, pg_class c, pg_class i WHERE ((c.oid = x.indrelid) AND (i.oid = x.indexrelid));
> 1187c1186
> < (20 rows)
> ---
> > (19 rows)
> ====== foreign_key ======
> 11a12
> > NOTICE: _outNode: don't know how to print type 726
> 235a237
> > NOTICE: _outNode: don't know how to print type 726
>
> I guess the error on foreign_key is caused by -d 3 turned on(does this
> hurt anything?) But what about the rules?
>
> Linux RedHat 4.2, multibyte support enabled.
Forget about the rules failure. I was tweaking pg_log file, and that
was the problem. Initdb again and the error has gone.
===
Subject: [PORTS] Postgres 7.0 on FreeBSD problem
From: David Bauer <bauer@genprofile.com>
Date: Sun, 28 May 2000 13:57:21 +0000
Hi,
I have just compiled the new 7.0 version on FreeBSD3.4.
The compilation was fine, but psql gives me this
error:
/usr/libexec/ld-elf.so.1: ../bin/psql: Undefined symbol "PQenv2encoding"
The 6.5.3 Version is running without any problems on this system
Any idea what's wrong here?
===
Subject: Re: [PORTS] Postgres 7.0 on FreeBSD problem
From: The Hermit Hacker <scrappy@hub.org>
Date: Sun, 28 May 2000 13:13:26 -0300 (ADT)
On Sun, 28 May 2000, David Bauer wrote:
> Hi,
>
> I have just compiled the new 7.0 version on FreeBSD3.4.
> The compilation was fine, but psql gives me this
> error:
>
> /usr/libexec/ld-elf.so.1: ../bin/psql: Undefined symbol "PQenv2encoding"
>
> The 6.5.3 Version is running without any problems on this system
> Any idea what's wrong here?
what does 'ldd ../bin/psql' show? do you have two different versions of
libpq installed on that machine (ie. 6.5.3 and v7.0)? Is it picking up
the wrong one?
===
Subject: [HACKERS] Re: [INTERFACES] Postgresql 7.0 JDBC exceptions - broken connections ?
From: Gunnar R|nning <gunnar@candleweb.no>
Date: 27 May 2000 11:30:27 +0200
Tom Lane <tgl@sss.pgh.pa.us> writes:
> I think that this and the "Tuple received before MetaData" issue could
> have a common cause, namely running out of memory on the client side
> and not recovering well. libpq is known to emit its equivalent of
> "Tuple received before MetaData" when the backend hasn't violated the
> protocol at all. What happens is that libpq runs out of memory while
> trying to accumulate a large query result, "recovers" by resetting
> itself to no-query-active state, and then is surprised when the next
> message is another tuple. (Obviously this error recovery plan needs
> work, but no one's got round to it yet.) I wonder whether the JDBC
> driver has a similar problem, and whether these queries could have
> been retrieving enough data to trigger it?
>
This could be a possible explanation, as some of the queries may indeed
retrieve large amounts of data. I have also noticed a couple of "Out of
Memory" exceptions that could be related(This seem to be "temporary" out of
memory exceptions, and not permanent memory leaks; so I guess these could
be caused by queries returning huge amounts of data).
> Another possibility is that the client app is failing to release
> query results when done with them, which would eventually lead to
> an out-of-memory condition even with not-so-large queries.
I don't think this is the case. I've been running the application through
OptimizeIT to profile memory and CPU usage and I haven't been able to spot
any memory leakages in the driver; The quality of the JDBC driver is
actually our main reason to migrate our application to PostgreSQL.
===
Subject: [HACKERS] 7.0 weirdness
From: Jeff MacDonald <jeff@pgsql.com>
Date: Tue, 30 May 2000 09:28:11 -0300 (ADT)
hi folks,
this query works fine in 6.5 but screwie in 7.0
7.0
gm=> SELECT DISTINCT gid FROM members
gm-> WHERE active = 't'
gm-> AND (gender = 0
gm-> AND (wantrstypemale LIKE '%Short Term%'
gm-> OR wantrstypemale like '%Marriage%'
gm-> OR wantrstypemale like '%Long Term%'
gm-> OR wantrstypemale like '%Penpal%'
gm-> OR wantrstypemale like '%Activity Partner%')
gm-> ) order by created desc;
ERROR: For SELECT DISTINCT, ORDER BY expressions must appear in target list
gm=>
===
Subject: [HACKERS] Re: [SQL] 7.0 weirdness
From: Jeff MacDonald <jeff@pgsql.com>
Date: Tue, 30 May 2000 11:10:24 -0300 (ADT)
On Tue, 30 May 2000, omid omoomi wrote:
> I'm not sure but may be that's because you are using select distinct and so
> there would be a few rows with same "gid" but different "created" fields in
> your table . And PG does not know which one to select and compare for ORDER
> BY clause. If that ,you would need to change the table structure to a better
> normal form.
gid is unique.. it's a serial..
funny thing is tho this worked on 6.5
oh well thanks for the info.
===
Subject: Re: [HACKERS] Re: [SQL] 7.0 weirdness
From: "Matthias Urlichs" <smurf@noris.de>
Date: Tue, 30 May 2000 16:31:35 +0200
Hi,
Jeff MacDonald:
> gid is unique.. it's a serial..
>
Then there is no point in using "DISTINCT" in the first place, is there?
> funny thing is tho this worked on 6.5
It happened to work because your gid is unique. But in the general case,
it can't work. Consider this table:
gid created
X 1
Y 2
X 3
Now, should your query's result be
gid
X
Y
or should it be
gid
Y
X
? And since the typical implementation throws away non-selected-for
columns before UNIQUEing, how should it be able to sort anything?
===
Subject: [HACKERS] Re: [SQL] 7.0 weirdness
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 30 May 2000 10:44:59 -0400
Jeff MacDonald <jeff@pgsql.com> writes:
> gid is unique.. it's a serial..
Mph. If you assume that gid is unique then the query would give
well-defined results, but if you know it's unique then why don't
you just leave off the DISTINCT?
> funny thing is tho this worked on 6.5
No, 6.5 merely failed to notice that it was giving you undefined
results.
===
Subject: [HACKERS] Re: [SQL] 7.0 weirdness
From: Peter Vazsonyi <neko@kredit.sth.szif.hu>
Date: Wed, 31 May 2000 08:45:08 +0200 (CEST)
> > >gm=> SELECT DISTINCT gid FROM members
> > >gm-> WHERE active = 't'
> > >gm-> AND (gender = 0
> > >gm-> AND (wantrstypemale LIKE '%Short Term%'
> > >gm-> OR wantrstypemale like '%Marriage%'
> > >gm-> OR wantrstypemale like '%Long Term%'
> > >gm-> OR wantrstypemale like '%Penpal%'
> > >gm-> OR wantrstypemale like '%Activity Partner%')
> > >gm-> ) order by created desc;
> > >ERROR: For SELECT DISTINCT, ORDER BY expressions must appear in target
I think you need a solution, and not explains...
Tom, and the others told the truth. You missed this query.
> gid is unique.. it's a serial..
I give you two ways:
1) gid __realy__ unique -> DISTINCT is unnecessary.
SELECT gid FROM members -- ... etc
2) gid not unique -> DISTINCT is not enough. ;(
SELECT gid,MAX(created) -- or MIN or AVG ... any aggregate
FROM members -- ... etc
GROUP BY gid ORDER BY 2; -- second colunm
===
Subject: Re: [PORTS] Problem getting 7.0 up and running
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 30 May 2000 16:29:36 +0000
You have another Postgres installation (probably from RPMs) in your
path. Get rid of it and try again...
===
Subject: [HACKERS] SET FSYNC command?
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Wed, 31 May 2000 10:03:15 +0900
In 7.0 release note, we have:
Add SET FSYNC and SHOW PG_OPTIONS commands(Massimo)
I'm confused by this since we don't seem to have SET FSYNC command.
test=# set fsync to on;
NOTICE: Unrecognized variable fsync
SET VARIABLE
Am I missing something?
Also if we have that command, I wonder it would be safe to issue on
the fly.
Comments?
===
Subject: Re: [HACKERS] SET FSYNC command?
From: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Tue, 30 May 2000 21:33:16 -0400 (EDT)
> In 7.0 release note, we have:
>
> Add SET FSYNC and SHOW PG_OPTIONS commands(Massimo)
>
> I'm confused by this since we don't seem to have SET FSYNC command.
>
> test=# set fsync to on;
> NOTICE: Unrecognized variable fsync
> SET VARIABLE
>
> Am I missing something?
>
> Also if we have that command, I wonder it would be safe to issue on
> the fly.
Gee, I think we removed it because we thought it would be unsafe, but
then Tom Lane made it safe, forgot to re-enable it.
===
Subject: [HACKERS] PG 7.0 crash on SELECT
From: Louis-David Mitterrand <cunctator@apartia.ch>
Date: Sun, 4 Jun 2000 17:21:49 +0200
Issuing the followin SELECT crashes PG 7.0:
auction=# SELECT a.id,a.title,a.id,(select CASE WHEN a.stopdate < 'now' THEN 'closed' ELSE 'open' end) as status,to_char(a.time,'DD-MM HH24:MI'),b.price FROM auction* a, bid b WHERE a.id = b.auctionid AND b.login = 'mito2';
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!# \q
Apparently PG doesn't like the (SELECT CASE ... ) statement, until I
added it everything went well.
Here are the table descriptions:
Table "auction"
Attribute | Type | Modifier
--------------+-----------+--------------------------------------------------
id | integer | not null default nextval('auction_id_seq'::text)
login | text | not null
startdate | timestamp | not null default now()
stopdate | timestamp | not null
description | text | not null
startprice | float8 | not null
reserveprice | float8 |
category | text | not null
imageurl | text |
title | text | not null
quantity | integer | default 1
time | timestamp | not null default now()
option | bigint |
Index: auction_pkey
Constraints: (quantity > 0)
(imageurl ~ '^http://'::text)
(stopdate > startdate)
((reserveprice ISNULL) OR (reserveprice > startprice))
Table "bid"
Attribute | Type | Modifier
-----------+-----------+------------------------
login | text | not null
auctionid | integer | not null
price | float8 | not null
quantity | integer | not null default 1
time | timestamp | not null default now()
Index: bid_pkey
===
Subject: Re: [HACKERS] PG 7.0 crash on SELECT
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 04 Jun 2000 14:57:06 -0400
Louis-David Mitterrand <cunctator@apartia.ch> writes:
> Issuing the followin SELECT crashes PG 7.0:
> auction=# SELECT a.id,a.title,a.id,(select CASE WHEN a.stopdate < 'now' THEN 'closed' ELSE 'open' end) as status,to_char(a.time,'DD-MM HH24:MI'),b.price FROM auction* a, bid b WHERE a.id = b.auctionid AND b.login = 'mito2';
> pqReadData() -- backend closed the channel unexpectedly.
> This probably means the backend terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !# \q
> Apparently PG doesn't like the (SELECT CASE ... ) statement, until I
> added it everything went well.
The crash certainly is a bug, but you could get around it for now
by not using an unnecessary sub-SELECT. Why not just
...,a.id,(CASE WHEN ...
regards, tom lane
===