Re: [HACKERS] Re: pg_dump possible fix, need testers. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Re: pg_dump possible fix, need testers.
Date
Msg-id 25723.948734983@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump possible fix, need testers.  (Patrick Welche <prlw1@newn.cam.ac.uk>)
Responses Re: [HACKERS] Re: pg_dump possible fix, need testers.
List pgsql-hackers
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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] fatal copy in/out error (6.5.3)