On 2019-12-03 09:15, Radosław Korzeniewski wrote: > Hello, > > wt., 3 gru 2019 o 14:27 Martin Simmons <mar...@lispworks.com > <mailto:mar...@lispworks.com>> napisał(a): > > Is the current timing useful for some other situation? > > > I do not understand your question. > > > It seems like a bug to me too. To continue your analogy, it is like the > restaurant forcing you to choose a dish when you book the table, > before you've > seen the menu of the day. > > > No, absolutely not. When you execute the copy job then all required data > is available and copy jobs simply start, so the menu is available when > you book a table. > But when you go to the restaurant then an admin stop you entering the > room and force you wait until the next day when menu changed - so it is> not > a surprise.
But if you showed up at breakfast time and the maitre'd has made you wait until supper before letting you have your table, he should not force you to make your menu selection from the breakfast menu. You should get to choose from the supper menu, because that's what the restaurant is serving from NOW. > Admin should not prevent a copy job from executing. This is the main > issue here in the code which is currently available. Nobody is arguing anything about preventing copy jobs from executing. > If you think it should work differently then you have to implement a > different kind of mechanism. And as I understand Heitor's answer the > solution is to link copy job with source job using Run=... directive. > Then your copy job will be executed when your source job finish. > > Compare it with VolumeToCatalog verify jobs for example, which > select the job > when they start, not when they are scheduled. > > > Yes. This is exactly the same situation. > > There is NO any link between source backup jobs and any > Copy/Migrate/Verify jobs (except the functionality described by Heitor), > so it is impossible to achieve what you request. It is how it was > designed and implemented. You could expect a different functionality so > it should be designed and developed. From a technical point of view we > have to add another indirect stage for job execution which will evaluate > job execution parameters just right before a real execution. Which I am trying to point out is how it should work. Runtime execution parameters for a job should be evaluated WHEN it is executed, and not before, so that the job reflects the state of reality at the time that it actually runs. I assert that pre-evaluating runtime parameters of a job possibly hours or days before the job actually runs is a design error. I am not trying to assert, nor have I at any point been trying to assert, that there is or should be any "link between source backup jobs and any Copy/Migrate/Verify jobs". You have invented that criterion and jammed it into my argument on your own, and you insist upon inserting it, which to me demonstrates that no, you do NOT understand my point, because you are arguing against something that I never said. This is my sole point: If you run a job whose selection criterion is a SQL query, rather than a Fileset, then when the job runs, its selection should be based upon what that SQL query returns *NOW*. Not on what it returned eight hours ago. Because the objects returned by that query eight hours ago may no longer exist, or the objects that you want the job to operate on might not exist YET when the job is *queued* - but you know they will exist by the time the job is *executed*. FORGET ABOUT LINKS between Copy jobs and source backups. That is irrelevant and I'm not arguing any such thing. FORGET that this is a Copy job. That's not the point. To state this in the most direct possible terms: I assert that it is a design error to evaluate ANY selection criteria for a job UNTIL you are ready to actually execute the job. Pre-evaluating a SQL selection at the time that the job is QUEUED, instead of when it begins execution - and this is the case REGARDLESS of whether it is a Copy job, it is true for ANY JOB WHATSOEVER - is a virtual guarantee that if the job sits in queue for any non-trivial period of time for any reason, then by the time the job is actually executed, its selection criteria will be WRONG, because the results of the SQL query hours or days ago are stale by the time the job is executed. This behavior is broken-by-design. Not INTENTIONALLY so, I'm sure, but nevertheless, broken by design. This is in part why job priorities exist: So that jobs can be *queued* together in groups, but *prioritized* to happen in a certain order when you care about their order. What is the point of being able to prioritize one job such that it runs only after another, if it is then executed against a no-longer-valid *state* incorrectly preserved from before the other job upon which it depends ran? At the moment, now that I understand the problem, I can work around it by scheduling the Copy job far enough after all the nightly backups that I am certain that under all normal circumstances, it will not be QUEUED until after they have all completed. But the existence of a workaround does not make it not a bug. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
