> However, we need to prefer something > > - > > always preferring the new sched scan could lead to bounces, so we > > can > > prefer (1) existing, (2) legacy-single type or (3) new-multi type, > > but > > not (4) new sched scan. > > Not sure I can follow. What is the difference between (1) and (2).
(1) would never cancel any existing sched scan, regardless of type (legacy vs. multi-capable) (2) would cancel an existing sched scan (in favour of a new one) if the existing one is multi-capable (3) would cancel an existing sched scan (in favour of a new one) if the existing one is legacy type > Also > what do you consider (4) new sched scan. You mean the additional > parameterization of the scheduled scan? No, I just meant any new request. > > I think preferring the existing would probably be best, i.e. refuse > > legacy if any sched scan is running, and refuse multi if legacy is > > running? > > Whatever the response above, I can understand this and it seems most > straightforward. So I tend agree this is our best option although > maybe for the wrong reason. :) johannes
