On Mon, 2002-09-02 at 09:35, Tatsuo Ishii wrote:
> You need not to specify --enable-syslog in 7.3 BTW.
OK, thanks.
> This happens because the path to shared objs are defined at the
> compile time. I think you don't get the failure once you install
> PostgreSQL. However it's not convenience since
I'm still getting conversion test failures on RH 7.2, 7.3, and Null beta.
My confiugre arguments are:
./configure --prefix=/opt/postgresql --with-java --with-python --with-openssl
--enable-syslog --enable-debug --enable-cassert
--enable-depend
It appears that the functions are not being loade
On Mon, 02 Sep 2002 01:20:51 -0400, Tom Lane wrote:
>
> My two cents: once we ship beta1 we should try really really hard to
> avoid forcing an initdb cycle before final release. We can make all the
> portability fixes and code fixes we like, but we have to avoid
> disk-file-contents changes and
On Fri, 2002-08-30 at 22:24, Joe Conway wrote:
> Well a "real" fix sounded like a lot of work, and no one had the right
> combination of time/desire/knowledge/skill to go implement it. The
> "workaround" fix was discussed in this more recent thread:
>
> http://archives.postgresql.org/pgsql-hack
on RH 7.2, 7.3, and Null Beta.
Here's the important part of the diff of expected (<) and results (>):
6a7
> ERROR: Function iso8859_1_to_utf8 does not exist
11c12
< ERROR: conversion name "myconv" already exists
---
> ERROR: Function iso8859_1_to_utf8 does not exist
15a17
> ERROR: Function i
On Fri, 2002-08-30 at 21:45, Joe Conway wrote:
> That's due to a glibc change and is expected, if not desired. Complain
> to Red Hat. For more info, see previous threads on HACKERS, notably this
> one:
>
> http://archives.postgresql.org/pgsql-hackers/2002-05/msg00740.php
Yeah, I remember that.
I know this one has been a pain, but I'm getting regression failures on:
abstime ... FAILED
tinterval... FAILED
test horology ... FAILED
under RedHat 7.3 and RedHat Null Beta.
Thanks,
Gordon.
--
"Far and away the best prize that life has to offer
Looks good now, all three environments (RH 7.2, RH 7.3, RH Null).
G.
On Fri, 2002-08-30 at 20:57, Tom Lane wrote:
> Hmm, I don't get that here. In CVS tip the regression tests pass,
> and a manual trial gives:
>
> test73=# alter table foo drop column bar;
> ERROR: Relation "foo" does not exis
Thanks, Tom,
My /etc/ld.so.conf didn't have /opt/postgresql/lib in it, yet when I
renamed /opt/postgresql (which was v7.2.2) to something else, the initdb
succeeded. I'm not sure why it went looking up there...
Thanks again,
Gordon.
--
"Far and away the best prize that life has to offer
is
the source on the RH Null box, and 'make check' can
successfully do the initdb.
Anyone else having issues on RH 7.3?
G.
On Fri, 30 Aug 2002 15:43:03 -0400, Gordon Runkle wrote:
> Using current CVS sources (as of 1500 EDT), 'make check' fails at the
> database initializat
Anyone else having issues on RH 7.3?
G.
On Fri, 30 Aug 2002 15:43:03 -0400, Gordon Runkle wrote:
> Using current CVS sources (as of 1500 EDT), 'make check' fails at the
> database initialization step.
>
> This box is running RH 7.3 with all current RH updates, and h
The alter_table regression test is now failing for me (RH Null).
It appears that the problem is that the backend is giving back a
different error message than expected when dropping a column from a
non-existent table:
-- try altering non-existent table, should fail
alter table foo drop column ba
Using current CVS sources (as of 1500 EDT), 'make check' fails at the
database initialization step.
This box is running RH 7.3 with all current RH updates, and has
successfully built Pg 7.2.1 and 7.2.2.
Here's how I'm configuring it (same as I'm doing under the RH Null Beta,
which works fine):
I'm using the current CVS (as of ~1930 EDT, 29AUG02) on RedHat's latest
beta (null). I find that I need to use the -U option when trying to use
psql and the new PGPASSWORDFILE variable.
Here's what I have in my ~/.pgpw file (pointed to by PGPASSWORDFILE):
localhost:*:az_audit:gar:test
This my
Hi folks,
I'm dead in the water with pg_clog errors:
Mar 19 18:25:05 nexus postgres[28736]: [6] FATAL 2: open of
/data00/pgdata/pg_clog/007D failed: No such file or directory
Mar 19 18:25:06 nexus postgres[22250]: [1] DEBUG: server process (pid
28736) exited with exit code 2
Mar 19 22:06:53 n
Hi folks,
I'm dead in the water with pg_clog errors:
Mar 19 18:25:05 nexus postgres[28736]: [6] FATAL 2: open of
/data00/pgdata/pg_clog/007D failed: No such file or directory
Mar 19 18:25:06 nexus postgres[22250]: [1] DEBUG: server process (pid 28736) exited
with exit code 2
Mar 19 22:06:53
I've been using 7.1beta? and RC? in
development for some time. beta5 -> beta6 required an
initdb, but the since then I've just compiled the new
version and installed it. No problems, and the feature
set is worth it for me.
Gordon Runkle
Integrated Dynamics, Inc.
--
It doesn't
17 matches
Mail list logo
