Обсуждение: Re: schema: pg_dump -s ipmeter (fwd)
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 ...
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
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
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? :)
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
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 ... :)