Hi Sergey,
thanks for the additional explanations. But I still do not understand.
Sergey Vojtovich, 03.02.2009 11:17:
...
> Clearing my_errno is just a workaround. As you pointed out there are two
> rules wrt my_errno:
> - it must be checked immediately after a function returned an error. There
> must be no calls to other functions that may change it's value between.
> - my_errno value must be set right before a function is going to return an
> error. There must be no calls to other functions that may change it's
> value between (that's why we have these tricks with save_errno at the
> bottom of myrg_open()).
Agree.
>
> It is fine to clear my_errno when we perform regular table open. But when we
> open it for repair (HA_OPEN_FOR_REPAIR), both of the above rules were violated.
Hm. Below you said "the caller seem to be fine". But violation of the
first rule is misbehavior of the caller. What do I miss here?
I agree that in case of HA_OPEN_FOR_REPAIR the second rule was violated.
I agree to fix it as you did. But how does it influence the reported
scenario? The possible changes of my_errno would happen after my_errno
was set to the intended value. But then we would see a wrong error
message for a failed open. However, the bug report complains about an
error message when the open should succeed, in which case my_errno
should not be touched anywhere.
Please help. There must be one step in between, which I miss. Perhaps
HA_OPEN_FOR_REPAIR is the key? I don't see, why this option should be
used in the test scenario:
mysql> select * from t3;
ERROR 1168 (HY000): Unable to open underlying table which is different
mysql> select * from t4;
ERROR 1168 (HY000): Unable to open underlying table which is different
>
> For example CHECK TABLE m1:
> - we successfully open first child
> - we failed to open second child due to mismatch in reclength, set my_errno
> to HA_ERR_WRONG_MRG_TABLE_DEF
> - we failed to open third child, because it doesn't exists, set my_errno to
> something like ENOENT
> - myrg_open() pretends that the tables were opened, returning m_info
Ok. But this looks like the reverse case. The caller sees m_info, thinks
all is ok, ignores my_errno and proceeds, though the open failed.
However, the case in the bug report described a case where the error
survived from the previous statement. That is, the open was successful,
but the caller thinks, it failed.
...
> No, the caller seem to be fine.
There must be some magic, which I didn't grasp yet. If the caller
handles my_errno correctly, but still complains, then myrg_open() must
return NULL and have the old my_errno set. But why should it do so when
all tables are fine?
Regards
Ingo
--
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028
