Re: [HACKERS] Re: pg_dump possible fix, need testers.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Re: pg_dump possible fix, need testers.
Дата
Msg-id 25723.948734983@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump possible fix, need testers.  (Patrick Welche <prlw1@newn.cam.ac.uk>)
Ответы Re: [HACKERS] Re: pg_dump possible fix, need testers.  (Patrick Welche <prlw1@newn.cam.ac.uk>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Some notes on optimizer cost estimates
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] fatal copy in/out error (6.5.3)