I'm CC'ng this to the -hackers list, as this may be something that should
be looked into more deeply, as ppl start looking at pg_dump'ng their
databases to upgrade to 7.0 ...
Included is a pg_dump from a 7.0 system that does work ... under my v6.5.3
system, doing the same thing dies at the \connect - ipmeter shown below
... the v6.5.3 system is what is running on postgresql.org/hub.org, which
is a FreeBSD 3.4-STABLE server ...
I'm going to try a build of v6.5.3 on my home machine and see if i can
recreate the seg fault ...
On Tue, 15 Feb 2000, Sevo Stille wrote:
> The Hermit Hacker wrote:
> >
> > Good question ... I'm getting:
> >
> > pq_recvbuf: unexpected EOF on client connection
> >
> > from the backend, which *sounds* like psql is crashing ...
> >
> > gdb shows it dying:
> >
> > (gdb) where
> > #0 0x4814d0bc in strcmp () from /usr/lib/libc.so.3
> > #1 0x804fb28 in becomeUser ()
> > #2 0x804f268 in dumpIndices ()
> > #3 0x80501fa in dumpSchemaIdx ()
> > #4 0x804a8c2 in main ()
> > #5 0x80494dd in _start ()
>
> Strange that it seems to trap the error and exit, though. Well, I'll
> have a look at the source.
>
> > I've just gotten v7.0 compiled and installed ...
>
> Good. That ought to isolate the error a bit further.
Its definitely not a problem with v7.0 ... just got her all up and
running, as far as the database is concerned ...
-----------------------------
CREATE OPERATOR >>= (PROCEDURE = port_pinecmp , LEFTARG = port , RIGHTARG = int4 );
\connect - ipmeter
CREATE UNIQUE INDEX "users_name_key" on "users" using btree ( "name" "text_ops" );
CREATE UNIQUE INDEX "importerstatus_filename_key" on "importerstatus" using btree ( "filename" "text_ops" );
-----------------------------
from what I can tell, its at the \connect - ipmeter part that it dumps ...