MARK CALLAGHAN wrote:
> In which cases must my_error be called?
In general, when executing the current SQL statement fails.
my_error() will set the error text / number / sqlstate in the
diagnostics area, used later to return an ok or error packet to the client.
There are a lot of asserts that can be used in debug to enforce
> The function create_file in sql_class.cc doesn't call my_error when
> my_create and init_io_cache fail. Does it assume that my_create and
> init_io_cache took care of that?
Yes, because of the MYF(MY_WME) flag given to the lower level code,
which basically delegates the responsibility of reporting the error to
the API invoked.
> I added code that called my_seek() and when the input is a pipe,
> my_seek() returns an error and my_errno==ESPIPE. But clients hang if
> my new code returns -1 without calling my_error.
It is hard to tell without looking at the code, but I would guess that:
If the client hangs, it is probably waiting for data where the server is
not sending any because the statement failed.
This could be because the server did not send an error packet properly ...
In turn, this could be because of the state of the diagnostics area ...
In turn, this could be because of a missing call to my_error ...
Looking at the code in mysys, it seems my_seek ignores the flags given
to it :(
You may have to call my_seek with MYF(0), and call my_error() explicitly.