Description:
Currently the number of fd's on windows is limited to 2048.
This is bad for performance, for many reasons, mostly windows servers
are stuck with a tiny table_cache or low number of concurrent connections,
compared with linux running on the same hardware.

How to repeat:
Run the server

mysqld-nt.exe --table_cache=1000 --max_connections=500 --open_files-limit=3000 --console

061122 17:04:27 [Warning] Could not increase number of max_open_files to more than 2048
(request: 2510)
061122 17:04:28  InnoDB: Started; log sequence number 0 43655
061122 17:04:28 [Note] mysqld-nt: ready for connections.
Version: '5.0.30-enterprise-gpl-nt'  socket: ''  port: 3306  MySQL Enterprise Server
(GPL)

Suggested fix:
Not sure.  Perhaps break away from posix and use native win32 api's on windows?

btw, I did tests using a small app, 100% win32 api, and found win2003 standard easily
opens 45000+ files at a time, and win2003 enterprise went even higher than that.

see bug #25222 for the win32 handle leak which occurs when _open_osfhandle fails.

I spent some time reading the MSDN information on this problem and there is indeed a hard
2048 file limit when using the _open_osfhandle() function. 
[See http://msdn2.microsoft.com/en-us/library/kdfaxaay(VS.80).aspx]

In order to work around this, the Win32 native HANDLEs should be used instead of the C
file handle.

2048 open posix file limit also exists on 64-bit windows even if binary is built as
64-bit. see attached testcase.

testcase.

Attachment: fileposix.cpp (text/plain), 844 bytes.

On my 64-bit XP, the debug binary asserts of you try increase limit > 2048 using
_setmaxstdio() call.

The only solution is to use 100% win32 handles for file i/o on windows, like innodb does.

any update on this?

can someone fix this? i have 100 log entries every day like this....

Could not increase number of max_open_files to more than 2048 (request: 10250)

mysql server is crashing all the time during the day when traffic is high. you should know
better than to release crappy software like this. these kind of bugs give opensource
software a really bad name.

This bug makes partitioning unusable on Windows for databases with any significant number
of tables/partitions.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/47394

2653 Vladislav Vaintroub	2008-06-04
      Bug#24509 - 2048 file descriptor limit on windows needs increasing, also 
      WL#3049 - improved Windows I/O
      
      The patch replaces the use of the POSIX I/O interfaces in mysys on Windows with 
      the Win32 API calls (CreateFile, WriteFile, etc). The Windows HANDLE for the open 
      file is stored in the my_file_info struct, along with a flag for append mode 
      (because the Windows API does not support opening files in append mode in all cases)
      The default max open files has been increased to 16384 and can be increased further
      by setting --max-open-files=<value> during the server start.
      
      Additionally, my_(f)stat() is changed to use __stati64 structure with  64 file size
and
      timestamps. It will now return correct file size now, unlike C runtime stat() that
may 
      report outdated info.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/47776

2657 Vladislav Vaintroub	2008-06-12
      Bug#24509 - 2048 file descriptor limit on windows needs increasing, also 
      WL#3049 - improved Windows I/O
      
      The patch replaces the use of the POSIX I/O interfaces in mysys on Windows with 
      the Win32 API calls (CreateFile, WriteFile, etc). The Windows HANDLE for the open 
      file is stored in the my_file_info struct, along with a flag for append mode 
      (because the Windows API does not support opening files in append mode in all cases)
      The default max open files has been increased to 16384 and can be increased further
      by setting --max-open-files=<value> during the server start.
            
      Another major change in this patch that almost all Windows specific file IO code
      has been moved to a new file my_winfile.c, greatly reducing the amount of code 
      in #ifdef blocks within mysys,  thus improving readability.
             
                  
      Minor enhancements:
      - my_(f)stat() is changed to use __stati64 structure with  64 file size
      and timestamps. It will now return correct file size now (C runtime implementation
      used to report outdated information)
      - my_lock on Windows is prepared to handle additional timeout parameter

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/47983

2657 Vladislav Vaintroub	2008-06-17
      Bug#24509 - 2048 file descriptor limit on windows needs increasing, also 
      WL#3049 - improved Windows I/O
            
      The patch replaces the use of the POSIX I/O interfaces in mysys on Windows with 
      the Win32 API calls (CreateFile, WriteFile, etc). The Windows HANDLE for the open 
      file is stored in the my_file_info struct, along with a flag for append mode 
      (because the Windows API does not support opening files in append mode in all cases)
      The default max open files has been increased to 16384 and can be increased further
      by setting --max-open-files=<value> during the server start.
                  
      Another major change in this patch that almost all Windows specific file IO code
      has been moved to a new file my_winfile.c, greatly reducing the amount of code 
      in #ifdef blocks within mysys,  thus improving readability.
                   
                        
      Minor enhancements:
        - my_(f)stat() is changed to use __stati64 structure with  64 file size
         and timestamps. It will now return correct file size now (C runtime
implementation
         used to report outdated information)
         - my_lock on Windows is prepared to handle additional timeout parameter
         - after review : changed __WIN__ to _WIN32 in the new and changed code.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/48035

2657 Vladislav Vaintroub	2008-06-18
      Bug#24509 - 2048 file descriptor limit on windows needs increasing, also 
      WL#3049 - improved Windows I/O
                  
      The patch replaces the use of the POSIX I/O interfaces in mysys on Windows with 
      the Win32 API calls (CreateFile, WriteFile, etc). The Windows HANDLE for the open 
      file is stored in the my_file_info struct, along with a flag for append mode 
      because the Windows API does not support opening files in append mode in all cases)
      The default max open files has been increased to 16384 and can be increased further
      by setting --max-open-files=<value> during the server start.
                        
      Another major change in this patch that almost all Windows specific file IO code
      has been moved to a new file my_winfile.c, greatly reducing the amount of code 
      in #ifdef blocks within mysys,  thus improving readability.
                         
                              
      Minor enhancements:
      - my_(f)stat() is changed to use __stati64 structure with  64 file size
        and timestamps. It will return correct file size now (C runtime implementation
        used to report outdated information)
      - my_lock on Windows is prepared to handle additional timeout parameter
      - after review : changed __WIN__ to _WIN32 in the new and changed code.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/48036

2657 Vladislav Vaintroub	2008-06-18
      Bug#24509 - 2048 file descriptor limit on windows needs increasing, also 
      WL#3049 - improved Windows I/O
                        
      The patch replaces the use of the POSIX I/O interfaces in mysys on Windows with 
      the Win32 API calls (CreateFile, WriteFile, etc). The Windows HANDLE for the open 
      file is stored in the my_file_info struct, along with a flag for append mode 
      because the Windows API does not support opening files in append mode in all cases)
      The default max open files has been increased to 16384 and can be increased further
      by setting --max-open-files=<value> during the server start.
                              
      Another major change in this patch that almost all Windows specific file IO code
      has been moved to a new file my_winfile.c, greatly reducing the amount of code 
      in #ifdef blocks within mysys, thus improving readability.
                               
                                    
      Minor enhancements:
      - my_(f)stat() is changed to use __stati64 structure with  64 file size
      and timestamps. It will return correct file size now (C runtime implementation
      used to report outdated information)
      - my_lock on Windows is prepared to handle additional timeout parameter
      - after review : changed __WIN__ to _WIN32 in the new and changed code.

Is this fix is coming in the next release 6.0?
I am stuck beacuse this is giving problem on merge tables created with union of more than
365*5 tables. (1 table a day) for last 5 yrs.

Ryan, yes, it will come with the 6.0 release(but not necessarily with the next beta)

Pushed into 6.0.8-alpha  (revid:vvaintroub@mysql.com-20080617233723-a89vz2gpurlk2p9k)
(version source revid:kpettersson@mysql.com-20080915213305-1ljm3tx7tgsdrne9) (pib:5)

Noted in 6.0.8 changelog.

On WIndows, use of POSIX I/O interfaces in mysys was replaced with
Win32 API calls (CreateFile(), WriteFile(), and so forth) and the 
default maximum number of open files has been increased to 16384. The
maximum can be increased further by using the --max-open-files=N
option at server startup.

Vladislav, thanks for polishing and integrating my Windows I/O patch.  There was supposed
to be a one line attribution for my efforts on this in the source code, not sure why that
got stripped out, but the code looks good.

Bug #44122 was marked as duplicate of this one.

Bug http://bugs.mysql.com/bug.php?id=44147 has been marked as duplicate of this one.