Re: [HACKERS] Another nasty cache problem
| От | Patrick Welche |
|---|---|
| Тема | Re: [HACKERS] Another nasty cache problem |
| Дата | |
| Msg-id | 20000131191356.B8582@quartz.newn.cam.ac.uk обсуждение исходный текст |
| Ответ на | Another nasty cache problem (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [HACKERS] Another nasty cache problem
|
| Список | pgsql-hackers |
Tom Lane wrote: > I'm down to the point where the parallel tests mostly work with a small > SI buffer --- but they do still sometimes fail. Have you committed your changes? I tried the parallel tests with cvs of around 5pm GMT 31 Jan, and they were all fine (I just ran out of procs at one point). This is much better than last week! Thanks! I also tried that nonsensical join from the other day, and it failed in the same way again: 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. After \. : Unknown protocol character 'M' read from backend. (The protocol character is the first character the backend sends in responseto a query it receives). PQendcopy: resetting connection Asynchronous NOTIFY 'ndropoulou' from backend with pid '1818589281' received. Asynchronous NOTIFY 'ndropoulou' from backend with pid '1818589281' received. pq_flush: send() failed: Broken pipe FATAL: pq_endmessage failed: errno=32 but no NOTICEs about SI anywhere any more, in fact no messages at all until the "Unknown protocol character" bit above. The psql frontend process grows to about 120Mb in size before this if that matters (200Mb swap free). (Looking at why pg_dumpall creates unique indices for each different type of index at the moment...) Cheers, Patrick
В списке pgsql-hackers по дате отправления: