launchpad-dev team mailing list archive

[Diogo Matsubara <matsubara@xxxxxxxxxxxxx>]

On Thu, Oct 14, 2010 at 1:35 AM, Robert Collins
<robert.collins@xxxxxxxxxxxxx> wrote:
> I just had a catchup with Stuart about this specific aspect of the
> change to pg 8.4.
>
> The current status is:
>  - many queries are faster
>  - some queries have regressed massively on staging and on prod
>  - some queries have regressed only on prod
>
> As a result, Stuarts recommending that we get a fresh OOPS for any
> timeout bugs filed before we were completely on pg 8.4 - some older
> bugs may be fixed now by ppostgresql improvements.
>
> He is currently trying to identify why some things are fast on staging
> and slow on production - I'm going to file a bug in a minute for this,
> because if staging is faster than prod at (well anything) it stops
> being a good predictor of production performance, and we need that
> predictive ability to avoid panics.
>
> I'm going to add a tag 'pg83' to all the existing timeout bugs; if
> you're looking at fixing a timeout bug with that tag, please find a
> fresh OOPS for it and remove the tag. If you can't find an OOPS, and
> the urls that were slow are consistently fast, I recommend you
> consider closing the bug (with a note that it may need to be
> reopened).
>
> That said, the OOPS system is currently a little sick - its not
> finding OOPS from lpnet, and Ursula couldn't see why; hopefully Diogo
> can look at it in 7-8 hours from now.

I disabled the script which loads oops reports into the oops database
while investigating bug
https://bugs.edge.launchpad.net/oops-tools/+bug/660218
It's now re-enabled and it's catching up.

>
> Cheers,
> Rob
>



-- 
Diogo M. Matsubara