Horton

Thread

  1. jaguar is up

    ohp@pyrenet.fr — 2007-11-28T16:28:33Z

    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: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

  2. Re: jaguar is up

    Tom Lane <tgl@sss.pgh.pa.us> — 2007-11-28T17:45:30Z

    ohp@pyrenet.fr 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

  3. Re: jaguar is up

    ohp@pyrenet.fr — 2007-11-28T18:30:57Z

    On Wed, 28 Nov 2007, Tom Lane wrote:

> Date: Wed, 28 Nov 2007 12:45:30 -0500
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
> Subject: Re: [HACKERS] jaguar is up
>
> ohp@pyrenet.fr 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: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

  4. Re: jaguar is up

    Greg Stark <stark@enterprisedb.com> — 2007-11-29T00:29:39Z

    "Tom Lane" <tgl@sss.pgh.pa.us> 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!

  5. Re: jaguar is up

    Tom Lane <tgl@sss.pgh.pa.us> — 2007-11-29T05:40:57Z

    Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> 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