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 ...
Mon, 14 Feb 2000 22:44:49 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: schema: pg_dump -s ipmeter (fwd)
On Mon, 14 Feb 2000, The Hermit Hacker wrote:

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

That looks more like a pg_dump trace to me. If you didn't know yet,
pg_dump 7.0 can't be used with previous databases, so maybe that's a
reason.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 15 Feb 2000 13:24:49 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Re: schema: pg_dump -s ipmeter (fwd)
Peter Eisentraut wrote:

> That looks more like a pg_dump trace to me.  If you didn't know yet,
> pg_dump 7.0 can't be used with previous databases, so maybe that's a
> reason.

If I got Marc right, pg_dump 6.5.3 was crashing on him while dumping
from a 6.5.3 db, and he can dump from 7.0 as well as from another 6.5.3
installation. It rather looks like becomeUser croaks the fourth time it
is called and the first time it is switching users, on that particular
installation. Might be something gone wrong with the user, but it could
as well be some obscure overflow problem that only rarely triggers. 

Sevo

Tue, 15 Feb 2000 13:58:02 +0100
Sevo Stille <sevo@ip23.net>
Re: [HACKERS] Re: schema: pg_dump -s ipmeter (fwd)
On Tue, 15 Feb 2000, Peter Eisentraut wrote:

> On Mon, 14 Feb 2000, The Hermit Hacker wrote:
> 
> > 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 ()
> 
> That looks more like a pg_dump trace to me. If you didn't know yet,
> pg_dump 7.0 can't be used with previous databases, so maybe that's a
> reason.

I *really* hope you don't mean that you cn't pg_dump from v6.5.3 (what I
was trying) and reload again into 7.0? :)



Tue, 15 Feb 2000 13:23:42 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: schema: pg_dump -s ipmeter (fwd)
On Tue, 15 Feb 2000, The Hermit Hacker wrote:

> I *really* hope you don't mean that you cn't pg_dump from v6.5.3 (what I
> was trying) and reload again into 7.0? :)

No, what I meant was that you can't use pg_dump 7.0 to dump non-7.0
databases. At least it was like this last time I tried it.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 15 Feb 2000 18:38:18 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Re: schema: pg_dump -s ipmeter (fwd)
On Tue, 15 Feb 2000, Peter Eisentraut wrote:

> On Tue, 15 Feb 2000, The Hermit Hacker wrote:
> 
> > I *really* hope you don't mean that you cn't pg_dump from v6.5.3 (what I
> > was trying) and reload again into 7.0? :)
> 
> No, what I meant was that you can't use pg_dump 7.0 to dump non-7.0
> databases. At least it was like this last time I tried it.

Okay, that I would expect ... :)



Tue, 15 Feb 2000 14:04:13 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: schema: pg_dump -s ipmeter (fwd)