Steve,
> You mentioned earlier that to get around the CS bug, avoid the query
> structures which trigger it. Dumb question: How do you isolate this?
In real terms, it's generally triggered by a query joining against a very
large table requiring a seq scan.
You can probably find the "bad queries" just by using PQA, and looking for
select, delete and update queries which last over 60 seconds.
> Is there a way in a Postgresql query to only look at 1 processor only in
> a dual-CPU setup?
That would be an OS question. I personally can't see how.
> Any likelyhood this CS storm will be understood in the next couple months?
It's well understood. See the archives of this list. The problem is that
implementing the solution is very, very hard -- 100+ hours from a top-notch
programmer. I'm still hoping to find a corporate sponsor for the issue ...
--
Josh Berkus
Aglio Database Solutions
San Francisco
