Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Actually what I *really* want is something closer to "show me all the >> unexplained failures", but unless Andrew is willing to support some way >> of tagging failures in the master database, I suppose that won't happen.
> Who would do the tagging, and how? Well, that's the hard part isn't it? I was sort of envisioning a group of users who'd be authorized to log in and set tags on database entries somehow. I'm not sure about details. One issue is that the majority of failures come in batches (when one of us commits a bad patch). With the current web interface it would be real tedious to verify which of the failures in a particular time interval matched the symptoms of a failure. What I did for my experiment this weekend was to download the last-stage-log of each failed build, which required an hour or so of setup time; then I could use grep to confirm which logs matched a failure that I'd identified. Doing that through the current webpage would involve lots of clicking and waiting. If we could expose a text-search-style API for grepping the stage logs, it'd be a lot easier to collect related failures. Then maybe a few widgets to let authorized users apply a tag to the search results ... I'm not entirely sure that this infrastructure would pay for itself, though. Without some users willing to take the time to separate explained from unexplained failures, it'd be a waste of effort. But we've already had a couple of cases of interesting failures going unnoticed because of the noise level. Between duplicate reports about busted patches and transient problems on particular build machines (out of disk space, misconfiguration, etc) it's pretty hard to not miss the once-in-a-while failures. Is there some other way we could attack that problem? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate