[HACKERS] Jaguar is up
Hmm, isn't 4h22m a LONG time for it even with clobbered cache? All my tests so far have last less than 2h.. Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Forwarded message -- Date: Thu, 29 Nov 2007 05:00:02 +0100 (CET) From: Cron Daemon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Cron [EMAIL PROTECTED] cd /home/ohp/build-farm ./run_build.pl --verbose [05:00:02] checking out source ... [05:01:00] checking if build run needed ... [05:01:04] copying source to pgsql.10004 ... [05:01:29] running configure ... [05:01:59] running make ... [05:05:28] running make check ... [06:28:20] running make contrib ... [06:28:44] running make install ... [06:28:49] setting up db cluster ... [06:35:17] starting db ... [06:35:18] running make installcheck ... [08:25:54] restarting db ... [08:25:56] running make PL installcheck ... [08:29:48] restarting db ... [08:29:50] running make contrib install ... [08:29:53] running make contrib installcheck ... [09:08:26] stopping db ... [09:08:27] running make ecpg check ... [09:22:01] OK ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Jaguar is up
[EMAIL PROTECTED] writes: Hmm, isn't 4h22m a LONG time for it even with clobbered cache? All my tests so far have last less than 2h.. I'm sure that yesterday' LookupOpclassInfo change would have made it even more mind-bogglingly slow than before... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] jaguar is up
Jaguar is a new animal meant to test specific defines as asked by Tom sometime ago. Right now, it compiles and runs with -DCLOBBER_CACHE_ALWAYS Let me know if you want me to add/change flags Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] jaguar is up
[EMAIL PROTECTED] writes: Jaguar is a new animal meant to test specific defines as asked by Tom sometime ago. Right now, it compiles and runs with -DCLOBBER_CACHE_ALWAYS Cool, how long does it take to run the regression tests? Let me know if you want me to add/change flags Awhile back I got burnt by a gap in that testing methodology: http://archives.postgresql.org/pgsql-committers/2006-12/msg00237.php I didn't do anything about it at the time, but now I am tempted to modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables its internal cache. Any objections? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] jaguar is up
On Wed, 28 Nov 2007, Tom Lane wrote: Date: Wed, 28 Nov 2007 12:45:30 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list pgsql-hackers@postgresql.org Subject: Re: [HACKERS] jaguar is up [EMAIL PROTECTED] writes: Jaguar is a new animal meant to test specific defines as asked by Tom sometime ago. Right now, it compiles and runs with -DCLOBBER_CACHE_ALWAYS Cool, how long does it take to run the regression tests? The whole thing is about 96 Min, did'nt check the exact time of regression tests but it's long on a dual core AMD centos 5.0 sata disk system Let me know if you want me to add/change flags Awhile back I got burnt by a gap in that testing methodology: http://archives.postgresql.org/pgsql-committers/2006-12/msg00237.php I didn't do anything about it at the time, but now I am tempted to modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables its internal cache. Any objections? Nope! regards, tom lane Tell me if you want me to set up other tests or change configure param. Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] jaguar is up
Tom Lane [EMAIL PROTECTED] writes: I didn't do anything about it at the time, but now I am tempted to modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables its internal cache. Any objections? That sounds not equivalent to receiving a relcache flush at any particular point in time where a relcache flush could be received. Wouldn't it make more sense (and test more code) to go ahead and cache all the same data but flush it whenever a relcache flush could possibly be received? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] jaguar is up
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: I didn't do anything about it at the time, but now I am tempted to modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables its internal cache. Any objections? That sounds not equivalent to receiving a relcache flush at any particular point in time where a relcache flush could be received. Wouldn't it make more sense (and test more code) to go ahead and cache all the same data but flush it whenever a relcache flush could possibly be received? CLOBBER_CACHE_ALWAYS already did that. I'm too lazy to go back and reconstruct the exact sequence of events that led to the problem last December, but the basic issue is that LookupOpclassInfo had its own caching in front of the syscache flush, and that was able to obscure a cache flush race condition that only happened when LookupOpclassInfo had to actually load data. If you really want to question this, I suggest loading up a CVS snapshot from late last December and trying to reproduce the intermittent buildfarm failures we were seeing then. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
