Re: bk commit into 5.0 tree (aelkin:1.2543) BUG#28597

[Andrei Elkin]

Sergei, hello.

> Hi!
>
> Ok to push without MY_UNPACK_FILENAME and with a shorter changeset
> comment. See below.
>
> On Nov 02, Andrei Elkin wrote:
>> ChangeSet@stripped, 2007-11-02 11:15:05+02:00, aelkin@stripped +3 -0
>>   Bug #28597 Replication doesn't start after upgrading to 5.1.18
>
> Please, commit with the "DOCUMENATION proposal", changeset comment is
> supposed to be short. Add this proposal to the bugreport instead.
>    

Sure. The idea was for you to review that part as well.


>>   Since bug@20166, which replaced the binlog file name generating to base
>>   on pidfile_name instead of the previous glob_hostname, the binlog file
>>   name suddenly started to be stored solely in the absolute path format,
>>   including a case when --log-bin option meant a relative path.
>>   What's more serious, the path for binlog file can lead unrequestedly 
>>   to pid-file directory so that after any proper fix for this bug
>>   there might be similar to the bug report consequences for one who
>>   upgrades from post-fix-bug@20166-pre-fix-bug@28597 to post-fix-bug@28597.
>>   
>>   Fixed with preserving`pidfile_name' (intr.by bug@20166) but stripping
>>   off its directory part. This restores the original logics of storing
>>   the names in compatible with --log-bin option format and with the
>>   requirement for --log-bin ralative path to corresond to the data directory.
>>   Side effects for this fix:
>>   
>>   effective fixing bug@27070, refining its test;
>>   ensuring no overrun for buff can happen anymore (Bug#31836 
>>   insufficient space reserved for the suffix of relay log file name);
>>   bug#31837  --remove_file $MYSQLTEST_VARDIR/tmp/bug14157.sql missed
>>   in rpl_temporary.test;
>>   fixes Bug@28603  Invalid log-bin default location;
>>   
>>   
>>   DOCUMENATION proposal.
>>   
>>   
>>   After upgrading either 5.0 or 5.1 master server from 
>>   a post-fix-bug#20166 release, a slave can fail in requesting to
>>   start dumping operation to receive the error
>>   "Could not find first log file name in binary log index file".
>>   
>>   In such case conduct the following procedure:
>>   
>>   1.  make sure the binlog index file resides in the requested directory -
>>       consider --datadir, --log-bin-index and --log-bin options.
>>       If not - they might be in --pid-file's directory - manually copy them
>>       to correspond to the options.
>>   2.  make sure the binlog index file lists names in compatible to --log-bin
>>       option format. If --log-bin is empty or means a relative path
>>       (e.g --log-bin=master) then the names in the file should be in
>>       the relative format such as
>>   
>>       ./your_hostname-bin.000001
>>       ./your_hostname-bin.000002
>>       ...
>>   
>>       or
>>   
>>       ./master-bin.000001
>>       ./master-bin.000002
>>       ...
>> 
>> diff -Nrup a/sql/log.cc b/sql/log.cc
>> --- a/sql/log.cc	2007-07-30 18:27:30 +03:00
>> +++ b/sql/log.cc	2007-11-02 11:15:01 +02:00
>> @@ -448,13 +448,11 @@ const char *MYSQL_LOG::generate_name(con
>>  {
>>    if (!log_name || !log_name[0])
>>    {
>> -    /*
>> -      TODO: The following should be using fn_format();  We just need to
>> -      first change fn_format() to cut the file name if it's too long.
>> -    */
>> -    strmake(buff, pidfile_name,FN_REFLEN-5);
>> -    strmov(fn_ext(buff),suffix);
>> -    return (const char *)buff;
>> +    strmake(buff, pidfile_name, FN_REFLEN - strlen(suffix) - 1);
>> +    return (const char *)
>> +      fn_format(buff, buff, "", suffix,
>> +                MYF(MY_UNPACK_FILENAME|MY_REPLACE_EXT|MY_REPLACE_DIR));
>

> Why do you need MY_UNPACK_FILENAME here ? It fixes the path by
> removing ".." and "/./" and expanding "~/". But with MY_REPLACE_DIR you
> remove the dirname of the path anyway.

Correct note. Removing the redundant.


>
> Regards / Mit vielen Grüssen,
> Sergei
>

Thanks for your notes and discussing this matter!


cheers,

Andrei