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

From Tom Lane
Subject Re: [HACKERS] Another nasty cache problem
Date
Msg-id 12080.949370550@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Another nasty cache problem  (Patrick Welche <prlw1@newn.cam.ac.uk>)
Responses Re: [HACKERS] Another nasty cache problem  (Patrick Welche <prlw1@newn.cam.ac.uk>)
List pgsql-hackers
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> 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!

Yes, I committed what I had last night (about 04:35 GMT 1/31).

There are cache-flush-related bugs still left to deal with, but they
seem to be far lower in probability than the ones squashed so far.
I'm finding that even with MAXNUMMESSAGES set to 8, the parallel tests
usually pass; so it seems we need some other way of testing to nail down
the remaining problems.

> 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

Hmm.  Can you provide a self-contained test case (a script to build the
failing tables, preferably)?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: [ADMIN] Attribute 'aggtransfn1' is repeated
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: Case-folding bogosity in new psql