Hello, On 5/25/21 18:14, Phil Stracchino wrote: > On 5/24/21 2:17 PM, Martin Simmons wrote: >>>>>>> On Fri, 21 May 2021 21:21:43 -0400, Phil Stracchino said: >>> Actually upon consideration of the shape of the curve I went with >>> VARBINARY(80). I'll be surprised if I ever see an LStat with length 75. >> >> I have some with length 76. But does it make any difference? I would expect >> the data storage size to be the same for any VARBINARY below something like >> 255. > > Well, true, yes. VARCHAR(80) doesn't actually save anything over > VARCHAR(96) unless there are values over 80 characters. Good point. I > suppose for prudence' sake 96 or even 128 would be safer.
I would recommend to not change this parameter, the LStat field size can vary from one platform to an other (on windows or FreeBSD, it is longer than on Linux). We may need to encode any kind of data into the field to get it back at the restore time and during the file selection. >>> What is Job.PriorJob used for? I have 486 rows currently in Job; in 480 >>> of them, including the 68 rows in which PriorJobId is non-zero, PriorJob >>> is NULL, while in the remaining six rows it is an empty string. Is it >>> even used? >> >> It seems to be new in version 11 and contains the Job.Job of the original Job >> in a Migration or Copy job. It is returned by the function >> BDB::bdb_find_job_start_time in src/cats/sql_find.c, where there is also a >> comment about it. > > > Ah, so... Yes, we track the original job name during copy or migration. Best Regards, Eric _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
