• unknown's avatar
    Fix for bug #31781: multi-table UPDATE with temp-pool enabled fails · 162eadbe
    unknown authored
                        with errno 17
    
    my_create() did not perform any checks for the case when a file is
    successfully created by a call to open(), but the call to
    my_register_filename() later fails because the number of open files
    has exceeded the my_open_files limit. This can happen on platforms 
    which do not have getrlimit(), and hence we do not know the real limit
    for open files. In such a case an error was returned to a caller
    although the file has actually been created. Since callers assume
    my_create() to return an error only when it failed to create a file,
    they did not perform any cleanups, leaving an 'orphaned' file on the
    file system.
    
    Fixed by adding a check for the above case to my_create() and ensuring
    the newly created file is deleted before returning an error.
    
    Creating a deterministic test case in the test suite is impossible,
    because the exact steps required to reproduce the above situation
    depend on the platform and/or environment (OS per-user limits, queries
    executed by previous tests, startup parameters). The patch was
    manually tested on Windows using examples posted in the bug report.
    
    
    mysys/my_create.c:
      Ensure that, if the call to my_register_filename() in my_create()
      failed, but the previous open() called succeeded, the newly created
      file is deleted before returning an error.
    162eadbe
my_create.c 2.56 KB