Re: [HACKERS] Another nasty cache problem - Mailing list pgsql-hackers

From Patrick Welche
Subject Re: [HACKERS] Another nasty cache problem
Date
Msg-id 20000131191356.B8582@quartz.newn.cam.ac.uk
Whole thread Raw
In response to Another nasty cache problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Another nasty cache problem
List 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 by date:

Previous
From: Ed Loehr
Date:
Subject: Re: [HACKERS] float4 confused as int??
Next
From: Ed Loehr
Date:
Subject: Re: [HACKERS] float4 confused as int??