I've just checked the IRC logs, and it looks likely that the above last dispatch on 2009-12-21 18:20:11 was the cause of a complete build farm failure (bug 499421), as there was some SQL run at that point:
{{{
update job set date_started = null
FROM
build, buildqueue bq, buildpackagejob bpj, archive
WHERE
bq.job = bpj.job AND
bpj.build = build.id AND
build.archive = archive.id AND
bq.builder is null AND
job.id = bpj.job AND
job.date_started is not null;
}}}
as setting the date_started back to null allowed the build farm to continue in a healthy state. But it does not leave the build in a healthy state. I assume (it would have been good to have had the build id) it is this build that was the culprit, and it had it's date_started set back to null, but the buildstate was still BUILDING - hence this oops.
I've just checked the IRC logs, and it looks likely that the above last dispatch on 2009-12-21 18:20:11 was the cause of a complete build farm failure (bug 499421), as there was some SQL run at that point:
https:/ /irclogs. canonical. com/2009/ 12/21/% 23launchpad- code.html# t19:35 (sorry for the non-open link)
which did:
{{{ date_started is not null;
update job set date_started = null
FROM
build, buildqueue bq, buildpackagejob bpj, archive
WHERE
bq.job = bpj.job AND
bpj.build = build.id AND
build.archive = archive.id AND
bq.builder is null AND
job.id = bpj.job AND
job.
}}}
as setting the date_started back to null allowed the build farm to continue in a healthy state. But it does not leave the build in a healthy state. I assume (it would have been good to have had the build id) it is this build that was the culprit, and it had it's date_started set back to null, but the buildstate was still BUILDING - hence this oops.