Re: [HACKERS] What's with the StartDb:2 failures on skylark?

2007-06-11 Thread Andrew Dunstan



Tom Lane wrote:

Every so often, buildfarm member skylark reports a StartDb:2 failure,
as for instance here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-06-10%2023:00:01
but the logs contain no trace of any actual failure.  What's happening,
and why is the buildfarm failing to record any useful information?

  



There is certainly something odd happening on the box. Magnus and I 
discussed it about a month ago and he was going to test something I 
suggested, but I'm not sure if he did. I have committed some small 
buildfarm changes that might take care of things. Marcus, can you please 
upgrade your run_build.pl to CVS HEAD (1.83) and we'll continue to keep 
an eye on things?


cheers

andrew

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] What's with the StartDb:2 failures on skylark?

2007-06-11 Thread Magnus Hagander
On Mon, Jun 11, 2007 at 10:23:06AM -0400, Andrew Dunstan wrote:
 
 
 Tom Lane wrote:
 Every so often, buildfarm member skylark reports a StartDb:2 failure,
 as for instance here:
 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-06-10%2023:00:01
 but the logs contain no trace of any actual failure.  What's happening,
 and why is the buildfarm failing to record any useful information?
 
   
 
 
 There is certainly something odd happening on the box. Magnus and I 
 discussed it about a month ago and he was going to test something I 
 suggested, but I'm not sure if he did. I have committed some small 
 buildfarm changes that might take care of things. Marcus, can you please 
 upgrade your run_build.pl to CVS HEAD (1.83) and we'll continue to keep 
 an eye on things?

Done.

FWIW, I think you wanted me to stick sleeps at some places in the code, but
I never managed to figure out where to put them. So if you want them in
somewhere, please tell me where to put them and I'll make sure to do that
as well.

//Magnus


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] What's with the StartDb:2 failures on skylark?

2007-06-11 Thread Andrew Dunstan



Magnus Hagander wrote:

On Mon, Jun 11, 2007 at 10:23:06AM -0400, Andrew Dunstan wrote:
  

Tom Lane wrote:


Every so often, buildfarm member skylark reports a StartDb:2 failure,
as for instance here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-06-10%2023:00:01
but the logs contain no trace of any actual failure.  What's happening,
and why is the buildfarm failing to record any useful information?

 
  
There is certainly something odd happening on the box. Magnus and I 
discussed it about a month ago and he was going to test something I 
suggested, but I'm not sure if he did. I have committed some small 
buildfarm changes that might take care of things. Marcus, can you please 
upgrade your run_build.pl to CVS HEAD (1.83) and we'll continue to keep 
an eye on things?



Done.

FWIW, I think you wanted me to stick sleeps at some places in the code, but
I never managed to figure out where to put them. So if you want them in
somewhere, please tell me where to put them and I'll make sure to do that
as well.


  


It's in the update - nothing else for you to do.

cheers

andrew

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate


[HACKERS] What's with the StartDb:2 failures on skylark?

2007-06-10 Thread Tom Lane
Every so often, buildfarm member skylark reports a StartDb:2 failure,
as for instance here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-06-10%2023:00:01
but the logs contain no trace of any actual failure.  What's happening,
and why is the buildfarm failing to record any useful information?

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match