On 5/29/21 5:15 AM, Eric Bollengier via Bacula-devel wrote:
> Hello Phil,
>> I have already in the past converted many of the TINYBLOB columns in my
>> Bacula catalog schema to VARBINARY with no ill effects. I now need to
>> redo a few of them because we just rewrote the File table. :)
>>
>> Fr
Hello Phil,
Thanks for your patch, I will apply it for 11.0.4, some more comments are
inline.
On 21.05.21 18:26, Phil Stracchino wrote:
Eric,
The following would be my first-cut patch.
The other way to handle restarting/resuming the copy operation when
updating to 11.0.2 would be instead of
Hello,
On 5/26/21 15:24, Phil Stracchino wrote:
> On 5/26/21 3:22 AM, Eric Bollengier via Bacula-devel wrote:
>> Hello,
>>
>> On 5/25/21 18:14, Phil Stracchino wrote:
>>> Well, true, yes. VARCHAR(80) doesn't actually save anything over
>>> VARCHAR(96) unless there are values over 80 characters.
On 5/26/21 3:22 AM, Eric Bollengier via Bacula-devel wrote:
> Hello,
>
> On 5/25/21 18:14, Phil Stracchino wrote:
>> 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
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 leng
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 m
> On Fri, 21 May 2021 21:21:43 -0400, Phil Stracchino said:
>
> On 5/21/21 5:13 PM, Phil Stracchino wrote:
> > On 5/21/21 12:26 PM, Phil Stracchino wrote:
> >>
> >> What is the maximum possible size of File.LStat? That is another good
> >> candidate to become a VARBINARY.
> >
> >
> > The la
On 5/21/21 5:13 PM, Phil Stracchino wrote:
> On 5/21/21 12:26 PM, Phil Stracchino wrote:
>>
>> What is the maximum possible size of File.LStat? That is another good
>> candidate to become a VARBINARY.
>
>
> The largest File.LStat value I have is 71 characters.
>
> +---+-
On 5/21/21 12:26 PM, Phil Stracchino wrote:
>
> What is the maximum possible size of File.LStat? That is another good
> candidate to become a VARBINARY.
The largest File.LStat value I have is 71 characters.
+---+--+
| length(LStat) | count(LStat) |
+---+
Eric,
The following would be my first-cut patch.
The other way to handle restarting/resuming the copy operation when
updating to 11.0.2 would be instead of truncating the file_temp table if
it already exists, create it with its PRIMARY key already in place and
then use INSERT IGNORE instead of a
On 5/21/21 11:29 AM, Phil Stracchino wrote:
>
> Well this is very interesting. My Bacula 11.0.2 source contains TWO
> copies of update_mysql_tables.in, and they're different sizes.
>
> minbar:root:/netstore/src/bacula-11.0.2:6 # find . -name
> update_mysql_tables.in -ls
> 4318424 5 -rw-r-
On 5/21/21 11:22 AM, Phil Stracchino wrote:
>> Thanks for the tips, they are very good. if you can provide a diff of the
>> update_mysql_tables.in script, I will apply it.
>>
>> Best Regards,
>> Eric
Well this is very interesting. My Bacula 11.0.2 source contains TWO
copies of update_mysql_table
On 5/21/21 10:14 AM, Eric Bollengier via Bacula-devel wrote:
> Hello Phil,
>
> On 5/21/21 15:49, Phil Stracchino wrote:
>> On 5/21/21 3:19 AM, Eric Bollengier via Bacula-devel wrote:
>>
>> I actually looked at it further and made additional changes to mine that
>> resolve that problem. Where the
Hello Phil,
On 5/21/21 15:49, Phil Stracchino wrote:
> On 5/21/21 3:19 AM, Eric Bollengier via Bacula-devel wrote:
>
> I actually looked at it further and made additional changes to mine that
> resolve that problem. Where the current script does this:
>
> DROP TABLE Filename;
> DROP TABLE File;
On 5/21/21 3:19 AM, Eric Bollengier via Bacula-devel wrote:
> Hello Phil,
>
> Thanks for the suggestions. I'm almost ready to apply them
> to the current update script.
>
> The only point that worries me is that if the break is done
> during the drop of the Filename/File tables or during the
> re
Hello Phil,
Thanks for the suggestions. I'm almost ready to apply them
to the current update script.
The only point that worries me is that if the break is done
during the drop of the Filename/File tables or during the
rename of the file_temp table, then if you restart the script
with your modifi
1. I recommend the following changes to update_mysql_tables:
--- update_mysql_tables.orig2021-05-19 12:54:15.226740443 -0400
+++ update_mysql_tables 2021-05-19 12:54:53.833949117 -0400
@@ -161,14 +161,14 @@
ALTER TABLE RestoreObject
MODIFY FileIndex INTEGER UNSIGNED DEFAULT 0;
ALTER TA
17 matches
Mail list logo
