Re: [HACKERS] Re: pg_dump possible fix, need testers.
От | Patrick Welche |
---|---|
Тема | Re: [HACKERS] Re: pg_dump possible fix, need testers. |
Дата | |
Msg-id | 20000124175921.F21345@quartz.newn.cam.ac.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: pg_dump possible fix, need testers. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: pg_dump possible fix, need testers.
|
Список | pgsql-hackers |
On Mon, Jan 24, 2000 at 12:29:43PM -0500, Tom Lane wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> writes: > > Things are still not so good for me. The pg_dumpall > file, psql < file did > > work, but later: > > > newnham=> select * from crsids,"tblPerson" where > newnham-> crsids.crsid != "tblPerson"."CRSID"; > > Backend sent B message without prior T > > D21Enter data to be copied followed by a newline. > > End with a backslash and a period on a line by itself. > >>> > > > which smells like a similar problem. (Note that this is a join. Straight > > selects didn't cause problems) > > Bizarre. Obviously, the frontend and backend have gotten out of sync, > but it's not too clear who's to blame. Since you also mention > > > (New also, though probably unrelated: the sanity check fails with number of > > index tuples exactly half number in heap - not equal) > > I think that you may have some subtle platform-specific problems in the > backend. > > What exactly is your platform/compiler/configuration, anyway? NetBSD-1.4P/i386 / egcs-2.91.66 19990314 (egcs-1.1.2 release) configure --enable-debug This morning I cvs'd made, installed, moved data->data2, initdb, started up postmaster, reloaded data (this worked!), then tried the join. It's a big one, so I thought I might as well stress it at the same time, and did a regression test. Anything I could try to narrow the problem down? Cheers, Patrick
В списке pgsql-hackers по дате отправления: