Re: ALTER TABLE lock strength reduction patch is unsafe

On 2/26/14, 9:15 AM, Simon Riggs wrote:
> On 26 February 2014 13:38, Andres Freund<andres(at)2ndquadrant(dot)com> wrote:
>> >Hi,
>> >
>> >On 2014-02-26 07:32:45 +0000, Simon Riggs wrote:
>>>> >> >* This definitely should include isolationtester tests actually
>>>> >> > performing concurrent ALTER TABLEs. All that's currently there is
>>>> >> > tests that the locklevel isn't too high, but not that it actually works.
>>> >>
>>> >>There is no concurrent behaviour here, hence no code that would be
>>> >>exercised by concurrent tests.
>> >
>> >Huh? There's most definitely new concurrent behaviour. Previously no
>> >other backends could have a relation open (and locked) while it got
>> >altered (which then sends out relcache invalidations). That's something
>> >that should be tested.
> It has been. High volume concurrent testing has been performed, per
> Tom's original discussion upthread, but that's not part of the test
> suite.
> For other tests I have no guide as to how to write a set of automated
> regression tests. Anything could cause a failure, so I'd need to write
> an infinite set of tests to prove there is no bug*somewhere*. How
> many tests are required? 0, 1, 3, 30?

ISTM that we don't want hand-written tests here, but rather generated tests that actually hit all potential cases. Obviously we'd never run that as part of normal reqression, but farm animals certainly could.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net