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

[Andrei Elkin]

Sergei, hello.

> Hi!
>
> On Oct 29, Andrei Elkin wrote:
>> ChangeSet@stripped, 2007-10-29 13:47:25+02:00, aelkin@stripped +3 -0
>>   Bug #28597 Replication doesn't start after upgrading to 5.1.18
>>   
>>   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 generating and its storing into the binlog index
>>   suddenly started to be solely in the absolute path format,
>>   including a case when --log-bin option meant a relative path.
>>   
>> 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-10-29 13:47:22 +02:00
>> @@ -821,8 +819,14 @@ int MYSQL_LOG::find_log_pos(LOG_INFO *li
>>  			    bool need_lock)
>>  {
>>    int error= 0;
>> +  uint flag= MYF(MY_RETURN_REAL_PATH);
>> +  char abs_path_bi[2*FN_REFLEN]; // abs path for binlog index file
>> +  char abs_path_lf[2*FN_REFLEN]; // for log file argument
>> +
>>    char *fname= linfo->log_file_name;
>>    uint log_name_len= log_name ? (uint) strlen(log_name) : 0;
>> +  if (log_name)
>> +    fn_format(abs_path_lf, log_name, mysql_real_data_home, "", flag);
>>    DBUG_ENTER("find_log_pos");
>>    DBUG_PRINT("enter",("log_name: %s", log_name ? log_name : "NULL"));
>
> Sorry, I don't understand.
> We've discussed at length that you should use MY_UNPACK_FILENAME here,
> and not MY_RETURN_REAL_PATH. And now you sumbit a new patch with
> MY_RETURN_REAL_PATH.
>

We spoke on that matter.

The major problem with MY_RETURN_REAL_PATH appears not to be extranous
stat() - which could be tolerated as it's still not that overkilling as
slave is supposed to connect once in a while (some other related
operations are similarly rare).
That's symlinks resolving which would clash with what recorded by
post-bug#20166 master in the binlog index - and you noted in telling
me to remove MY_RESOLVE_LINK.

The funniest thing, however, is none of these.
I found - sigh - found we are doomed trying to save
upgrades from post-bug#20166 to post-bug#28597.

Now why.

if the post-bug#20166 master generated binlog name, the file is
created in --pid-file's directory (bug#27070).
While the master does not upgrade neither change --pid-file nor
--log-bin (from empty) the binlog name sent by the slave is resolved
and the file is found.
All think the file is in data home directory.

After we fixed the current bug --pid-file won't apply anymore
and the binlog files are to be searched in the data directory.
But mysql_real_data_home is not necessarily is the same as
--pid-file's one.

So, here is the dead end: the post-bug#20166 can create a binlog file
in --pid-file directory but the post-bug#28597 won't find this file
anymore.

I officially gave out 3 of 4 hunk done in log.cc leaving only the
first hunk that "reverts" to pre-bug#20166 logics of the binlog name
constructing.

cheers,

Andrei