summaryrefslogtreecommitdiff
path: root/mysys
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.2 into 10.3Marko Mäkelä2019-02-194-32/+98
|\
| * MDEV-18204 - fixupVladislav Vaintroub2019-02-191-1/+2
| |
| * MDEV-18204 Fix rocksdb incremental backupVladislav Vaintroub2019-02-181-0/+60
| | | | | | | | | | Fix incremental prepare to copy #rocksdb subdirectory from the incremental dir.
| * Merge 10.1 into 10.2Marko Mäkelä2019-02-031-4/+3
| |\ | | | | | | | | | | | | | | | Temporarily disable a test for commit 2175bfce3e9da8332f10ab0e0286dc93915533a2 because fixing it in 10.2 requires updating libmariadb.
| | * Merge 10.1 into 10.1Marko Mäkelä2019-02-021-4/+3
| | |\ | | | | | | | | | | | | This is joint work with Oleksandr Byelkin.
| | | * Merge branch '5.5' into 10.0Oleksandr Byelkin2019-01-281-4/+3
| | | |\
| | | | * MDEV-18360 Prevent set_max_open_files from allocating too many filesVicențiu Ciorbaru2019-01-271-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the rlimit.rlim_cur value returned by getrlimit is not the RLIM_INFINITY magic constant, but a *very* large number, we can allocate too many open files. Restrict set_max_open_files to only return at most max_file_limit, as passed via its parameter.
| * | | | Merge 10.1 into 10.2Marko Mäkelä2019-02-022-28/+34
| |\ \ \ \ | | |/ / /
| | * | | my_malloc(): Invoke TRASH_ALLOC even WITH_SAFEMALLOC=OFFMarko Mäkelä2019-02-011-0/+1
| | | | |
| | * | | MDEV-10963 Fragmented BINLOG queryAndrei Elkin2019-01-241-28/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem was originally stated in http://bugs.mysql.com/bug.php?id=82212 The size of an base64-encoded Rows_log_event exceeds its vanilla byte representation in 4/3 times. When a binlogged event size is about 1GB mysqlbinlog generates a BINLOG query that can't be send out due to its size. It is fixed with fragmenting the BINLOG argument C-string into (approximate) halves when the base64 encoded event is over 1GB size. The mysqlbinlog in such case puts out SET @binlog_fragment_0='base64-encoded-fragment_0'; SET @binlog_fragment_1='base64-encoded-fragment_1'; BINLOG @binlog_fragment_0, @binlog_fragment_1; to represent a big BINLOG. For prompt memory release BINLOG handler is made to reset the BINLOG argument user variables in the middle of processing, as if @binlog_fragment_{0,1} = NULL is assigned. Notice the 2 fragments are enough, though the client and server still may need to tweak their @@max_allowed_packet to satisfy to the fragment size (which they would have to do anyway with greater number of fragments, should that be desired). On the lower level the following changes are made: Log_event::print_base64() remains to call encoder and store the encoded data into a cache but now *without* doing any formatting. The latter is left for time when the cache is copied to an output file (e.g mysqlbinlog output). No formatting behavior is also reflected by the change in the meaning of the last argument which specifies whether to cache the encoded data. Rows_log_event::print_helper() is made to invoke a specialized fragmented cache-to-file copying function which is copy_cache_to_file_wrapped() that takes care of fragmenting also optionally wraps encoded strings (fragments) into SQL stanzas. my_b_copy_to_file() is refactored to into my_b_copy_all_to_file(). The former function is generalized to accepts more a limit argument to constraint the copying and does not reinitialize anymore the cache into reading mode. The limit does not do any effect on the fully read cache.
* | | | | my_close: Don't retry on closeDaniel Black2019-02-131-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to close(2) "Retrying the close() after a failure return is the wrong thing to do" Even the EINTR case its maybe closed. Take the prudent approach here an risk leaking one file descriptor rather than closing one that is nolonger ours.
* | | | | Don't retry on closeDaniel Black2019-02-061-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to close(2) "Retrying the close() after a failure return is the wrong thing to do" Corrects 5c81cb880a054f34803e2821489533274ebf6c4e in MDEV-15635
* | | | | MDEV-17401: LOAD DATA from very big file into MyISAM table results in EOF ↵Oleksandr Byelkin2019-01-251-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | error and corrupt index fix of incorrect 10.3 merge
* | | | | Merge 10.2 into 10.3Marko Mäkelä2019-01-171-1/+1
|\ \ \ \ \ | |/ / / /
| * | | | Merge 10.1 into 10.2Marko Mäkelä2019-01-171-1/+1
| |\ \ \ \ | | |/ / /
| | * | | Merge 10.0 into 10.1Marko Mäkelä2019-01-171-1/+1
| | |\ \ \ | | | |/ /
| | | * | safemalloc: warn, flush after fprintfDaniel Black2019-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | Corrects 94d722b6a43b86ee760f07915921cf58f9869a5d
* | | | | safemalloc: put bad_ptr error arguments in right orderDaniel Black2019-01-171-1/+1
| | | | |
* | | | | Merge 10.2 into 10.3Marko Mäkelä2018-11-072-7/+23
|\ \ \ \ \ | |/ / / /
| * | | | Merge 10.1 into 10.2Marko Mäkelä2018-11-073-29/+49
| |\ \ \ \ | | |/ / /
| | * | | Merge 10.0 into 10.1Marko Mäkelä2018-11-073-29/+49
| | |\ \ \ | | | |/ /
| | | * | Merge 5.5 into 10.0Marko Mäkelä2018-11-073-29/+49
| | | |\ \ | | | | |/
| | | | * MDEV-17401: LOAD DATA from very big file into MyISAM table results in EOF ↵Oleksandr Byelkin2018-11-023-31/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | error and corrupt index my_read fixed as in higher versions. my_pread made as my_read aware of partial read of huge chunks of files MY_FULL_IO enabled for file operations
* | | | | Merge 10.2 into 10.3Marko Mäkelä2018-11-064-4/+24
|\ \ \ \ \ | |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | main.derived_cond_pushdown: Move all 10.3 tests to the end, trim trailing white space, and add an "End of 10.3 tests" marker. Add --sorted_result to tests where the ordering is not deterministic. main.win_percentile: Add --sorted_result to tests where the ordering is no longer deterministic.
| * | | | Merge 10.1 into 10.2Marko Mäkelä2018-11-064-4/+15
| |\ \ \ \ | | |/ / /
| | * | | Merge branch '10.0' into 10.1Sergei Golubchik2018-10-303-2/+10
| | |\ \ \ | | | |/ /
| | | * | Merge branch '5.5' into 10.0Sergei Golubchik2018-10-272-2/+3
| | | |\ \ | | | | |/
| | | | * Merge branch 'mysql/5.5' into 5.5Sergei Golubchik2018-10-232-8/+10
| | | | |\
| | | | | * Bug#27788907 SOME FILE OPERATIONS IN MF_IOCACHE2.C ARE NOT INSTRUMENTEDmysql-5.5.62Marc Alff2018-08-201-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MySQL bug number 90264 Contribution by Yura Sorokin. Problem: File mysys/mf_iocache2.c contains non instrumented file io operations. This causes inaccurate statistics in PERFORMANCE_SCHEMA. Solution: Use the instrumentation apis (mysql_file_tell instead of my_tell, etc).
| | | | | * Bug #26275510 BUNDLED ZLIB DOESN'T INCLUDE FIXES FOR SOME VULNERABILITIESAditya A2018-07-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Upgrading the zlib lib to 1.2.11
| | | * | | MDEV-17020: Assertion `length > 0' failed in ptr_compare upon ORDER BY with ↵Varun Gupta2018-10-151-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bad conversion This assert is hit when we do filesort using the priority queue and try to insert elements in the queue. The compare function used for the priority queue should handle the case for zerolength sortkey.
| | * | | | MDEV-17133 dump thread reads from a past positionAndrei Elkin2018-10-211-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to logs analysis the Dump thread attempted to read again data which was already sent. The reason of regressed read turns out in an _my_b_cache_read() early exit branch which missed to distinguish between total zero size read (e.g ineffective read when Count argument is zero) from a case when the requested amount of data is fully read out by sole accessing the cache's file. In the latter case such then *effective* reading was not reflected in the cache's state to screw the cache's state. Fixed with a check introduced of whether the file reading was effective prior to early exit. When this is the case conduct standard cache state change to account the actual read size. Notice the bug can show up also as an error to read binlog event e.g through BINLOG_GTID_POS() (of MDEV-16886).
| * | | | | MDEV-12779 Oracle/DB2 Compatibility Implicit Ordering for ROW_NUMBER OVERVicențiu Ciorbaru2018-11-011-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users expect window functions to produce a certain ordering of rows in the final result set. Although the standard does not require this, we already have the filesort result done for when we computed the window function. If there is no ORDER BY attached to the query, just keep it till the SELECT is completely evaluated and use that to print the result. Update test cases as many did not take care to guarantee a stable result.
* | | | | | Merge branch '10.2' into 10.3Sergei Golubchik2018-09-281-1/+2
|\ \ \ \ \ \ | |/ / / / /
| * | | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-09-241-1/+2
| |\ \ \ \ \ | | |/ / / /
| | * | | | Merge branch '10.0' into 10.1Sergei Golubchik2018-09-231-1/+2
| | |\ \ \ \ | | | |/ / /
| | | * | | Merge 5.5 into 10.0Marko Mäkelä2018-09-211-1/+2
| | | |\ \ \ | | | | |/ /
| | | | * | MDEV-17248 Improve ASAN memory pool instrumentationEugene Kosov2018-09-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | alloc_root(): unpoison only requested amount of bytes instead of a possible bigger aligned-sized buffer.
* | | | | | Merge 10.2 into 10.3Marko Mäkelä2018-08-031-1/+4
|\ \ \ \ \ \ | |/ / / / /
| * | | | | Merge 10.1 into 10.2Marko Mäkelä2018-08-021-1/+4
| |\ \ \ \ \ | | |/ / / /
| | * | | | Merge branch '10.0' into bb-10.1-merge-sanjaOleksandr Byelkin2018-07-251-1/+4
| | |\ \ \ \ | | | |/ / /
| | | * | | MDEV-11741 handler::ha_reset(): Assertion ↵Sergei Golubchik2018-07-191-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `bitmap_is_set_all(&table->s->all_set)' failed or server crash in mi_reset or buffer overrun or unexpected ER_CANT_REMOVE_ALL_FIELDS MEMORY table could be renamed into a non-extistent database. rename() is documented to return ENOENT when the source file does not exist OR when the target directory not exist. Nonexistent source .frm file is ok (table can still exist in the engine), nonexistent target directory is not. Make my_rename to use ENOTDIR for the latter case. Make RENAME TABLE issue an appropriate error ("unknown database" instead of "unknown table")
* | | | | | Merge branch '10.2' into 10.3Sergei Golubchik2018-06-301-1/+1
|\ \ \ \ \ \ | |/ / / / /
| * | | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-06-211-1/+1
| |\ \ \ \ \ | | |/ / / /
| | * | | | Merge branch '10.0-galera' into 10.1Vicențiu Ciorbaru2018-06-121-1/+1
| | |\ \ \ \
| | | * \ \ \ Merge tag 'mariadb-10.0.35' into 10.0-galeraJan Lindström2018-05-072-5/+7
| | | |\ \ \ \ | | | | |/ / /
| | | * | | | Merge remote-tracking branch 'origin/5.5-galera' into 10.0-galeraJan Lindström2018-05-074-7/+8
| | | |\ \ \ \
| | | | * \ \ \ Merge tag 'mariadb-5.5.60' into 5.5-galeraJan Lindström2018-04-247-46/+85
| | | | |\ \ \ \ | | | | | | |/ / | | | | | |/| |
| | | | * | | | MDEV-8743: use O_CLOEXEC MYSQL_LOG::open / TC_LOG_MMAP::openDaniel Black2018-03-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For galera compatibility, the main thing is to ensure the FD 1, 2 are not opened with O_CLOEXEC otherwise galera sst errors don't appear in the error.log Files without O_CLOEXEC from the test below: 0 -> /dev/pts/9 1 -> /tmp/error.log (intended) 2 -> /tmp/error.log (intended) 5 -> /tmp/datadir 6 -> /tmp/datadir/aria_log.00000001 (Innodb temp files) 8 -> /tmp/ibIIrhFL (deleted) 9 -> /tmp/ibfx1vai (deleted) 10 -> /tmp/ibAQUKFO (deleted) 11 -> /tmp/ibWBQSHR (deleted) 15 -> /tmp/ibEXEcfo (deleted) 20 -> /tmp/datadir/mysql/host.MYD 22 -> /tmp/datadir/mysql/user.MYD ... (rest of MYD files) Test for this and the previous commit. sql/mysqld --skip-networking --datadir=/tmp/datadir --log-bin=/tmp/datadir/mysqlbin --socket /tmp/s.sock --lc-messages-dir=${PWD}/sql/share --verbose --log-error=/tmp/error.log --general-log-file=/tmp/general.log --general-log=1 --slow-query-log-file=/tmp/slow.log --slow-query-log=1 180302 10:56:41 [Note] sql/mysqld (mysqld 5.5.60-MariaDB-wsrep) starting as process 26056 ... $ cd /proc/26056 $ ls -la --sort=none fd total 0 dr-x------. 2 dan dan 0 Mar 2 10:57 . dr-xr-xr-x. 9 dan dan 0 Mar 2 10:56 .. lrwx------. 1 dan dan 64 Mar 2 10:57 0 -> /dev/pts/9 l-wx------. 1 dan dan 64 Mar 2 10:57 1 -> /tmp/error.log l-wx------. 1 dan dan 64 Mar 2 10:57 2 -> /tmp/error.log lrwx------. 1 dan dan 64 Mar 2 10:57 3 -> /tmp/datadir/mysqlbin.index lrwx------. 1 dan dan 64 Mar 2 10:57 4 -> /tmp/datadir/aria_log_control lr-x------. 1 dan dan 64 Mar 2 10:57 5 -> /tmp/datadir lrwx------. 1 dan dan 64 Mar 2 10:57 6 -> /tmp/datadir/aria_log.00000001 lrwx------. 1 dan dan 64 Mar 2 10:57 7 -> /tmp/datadir/ibdata1 lrwx------. 1 dan dan 64 Mar 2 10:57 8 -> /tmp/ibIIrhFL (deleted) lrwx------. 1 dan dan 64 Mar 2 10:57 9 -> /tmp/ibfx1vai (deleted) lrwx------. 1 dan dan 64 Mar 2 10:57 10 -> /tmp/ibAQUKFO (deleted) lrwx------. 1 dan dan 64 Mar 2 10:57 11 -> /tmp/ibWBQSHR (deleted) lrwx------. 1 dan dan 64 Mar 2 10:57 12 -> /tmp/datadir/ib_logfile0 lrwx------. 1 dan dan 64 Mar 2 10:57 13 -> /tmp/datadir/ib_logfile1 l-wx------. 1 dan dan 64 Mar 2 10:57 14 -> /tmp/slow.log lrwx------. 1 dan dan 64 Mar 2 10:57 15 -> /tmp/ibEXEcfo (deleted) l-wx------. 1 dan dan 64 Mar 2 10:57 16 -> /tmp/general.log lrwx------. 1 dan dan 64 Mar 2 10:57 17 -> socket:[1897356] lrwx------. 1 dan dan 64 Mar 2 10:57 18 -> socket:[45335] l-wx------. 1 dan dan 64 Mar 2 10:57 19 -> /tmp/datadir/mysqlbin.000004 lrwx------. 1 dan dan 64 Mar 2 10:57 20 -> /tmp/datadir/mysql/host.MYD lrwx------. 1 dan dan 64 Mar 2 10:57 21 -> /tmp/datadir/mysql/host.MYI lrwx------. 1 dan dan 64 Mar 2 10:57 22 -> /tmp/datadir/mysql/user.MYD lrwx------. 1 dan dan 64 Mar 2 10:57 23 -> /tmp/datadir/mysql/user.MYI lrwx------. 1 dan dan 64 Mar 2 10:57 24 -> /tmp/datadir/mysql/db.MYD lrwx------. 1 dan dan 64 Mar 2 10:57 25 -> /tmp/datadir/mysql/db.MYI lrwx------. 1 dan dan 64 Mar 2 10:57 26 -> /tmp/datadir/mysql/proxies_priv.MYD lrwx------. 1 dan dan 64 Mar 2 10:57 27 -> /tmp/datadir/mysql/proxies_priv.MYI lrwx------. 1 dan dan 64 Mar 2 10:57 28 -> /tmp/datadir/mysql/tables_priv.MYD lrwx------. 1 dan dan 64 Mar 2 10:57 29 -> /tmp/datadir/mysql/tables_priv.MYI lrwx------. 1 dan dan 64 Mar 2 10:57 30 -> /tmp/datadir/mysql/columns_priv.MYD lrwx------. 1 dan dan 64 Mar 2 10:57 31 -> /tmp/datadir/mysql/columns_priv.MYI lrwx------. 1 dan dan 64 Mar 2 10:57 32 -> /tmp/datadir/mysql/procs_priv.MYD lrwx------. 1 dan dan 64 Mar 2 10:57 33 -> /tmp/datadir/mysql/procs_priv.MYI lrwx------. 1 dan dan 64 Mar 2 10:57 34 -> /tmp/datadir/mysql/servers.MYD lrwx------. 1 dan dan 64 Mar 2 10:57 35 -> /tmp/datadir/mysql/servers.MYI lrwx------. 1 dan dan 64 Mar 2 10:57 36 -> /tmp/datadir/mysql/event.MYD lrwx------. 1 dan dan 64 Mar 2 10:57 37 -> /tmp/datadir/mysql/event.MYI O_CLOEXEC files are those with flags 02000000 /usr/include/bits/fcntl-linux.h:# define __O_CLOEXEC 02000000 /usr/include/bits/fcntl-linux.h:# define O_CLOEXEC __O_CLOEXEC /* Set close_on_exec. */ $ find fdinfo/ -type f -ls -exec cat {} \; | more 1924720 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/0 pos: 0 flags: 0100002 mnt_id: 25 1924721 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/1 pos: 9954 flags: 0102001 mnt_id: 82 1924722 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/2 pos: 10951 flags: 0102001 mnt_id: 82 1924723 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/3 pos: 116 flags: 02100002 mnt_id: 82 1924724 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/4 pos: 52 flags: 0100002 mnt_id: 82 lock: 1: POSIX ADVISORY WRITE 26056 00:2c:1866365 0 EOF 1924725 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/5 pos: 0 flags: 0100000 mnt_id: 82 1924726 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/6 pos: 16384 flags: 0100002 mnt_id: 82 1924727 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/7 pos: 0 flags: 02100002 mnt_id: 82 lock: 1: POSIX ADVISORY WRITE 26056 00:2c:1866491 0 EOF 1924728 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/8 pos: 0 flags: 0100002 mnt_id: 82 1924729 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/9 pos: 0 flags: 0100002 mnt_id: 82 1924730 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/10 pos: 0 flags: 0100002 mnt_id: 82 1924731 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/11 pos: 0 flags: 0100002 mnt_id: 82 1924732 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/12 pos: 0 flags: 02100002 mnt_id: 82 lock: 1: POSIX ADVISORY WRITE 26056 00:2c:1866492 0 EOF 1924733 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/13 pos: 0 flags: 02100002 mnt_id: 82 lock: 1: POSIX ADVISORY WRITE 26056 00:2c:1866493 0 EOF 1924734 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/14 pos: 763 flags: 02102001 mnt_id: 82 1924735 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/15 pos: 0 flags: 0100002 mnt_id: 82 1924736 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/16 pos: 473 flags: 02102001 mnt_id: 82 1924737 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/17 pos: 0 flags: 02000002 mnt_id: 9 1924738 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/18 pos: 0 flags: 02 mnt_id: 9 1924739 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/19 pos: 245 flags: 02100001 mnt_id: 82 1924740 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/20 pos: 0 flags: 0100002 mnt_id: 82 1924741 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/21 pos: 503 flags: 0500002 mnt_id: 82 1924742 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/22 pos: 324 flags: 0100002 mnt_id: 82 1924743 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/23 pos: 642 flags: 0500002 mnt_id: 82 1924744 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/24 pos: 880 flags: 0100002 mnt_id: 82 1924745 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/25 pos: 581 flags: 0500002 mnt_id: 82 1924746 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/26 pos: 1386 flags: 0100002 mnt_id: 82 1924747 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/27 pos: 498 flags: 0500002 mnt_id: 82 1924748 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/28 pos: 0 flags: 0100002 mnt_id: 82 1924749 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/29 pos: 513 flags: 0500002 mnt_id: 82 1924750 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/30 pos: 0 flags: 0100002 mnt_id: 82 1924751 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/31 pos: 494 flags: 0500002 mnt_id: 82 1924752 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/32 pos: 0 flags: 0100002 mnt_id: 82 1924753 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/33 pos: 535 flags: 0500002 mnt_id: 82 1924754 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/34 pos: 0 flags: 0100002 mnt_id: 82 1924755 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/35 pos: 396 flags: 0500002 mnt_id: 82 1924756 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/36 pos: 0 flags: 0100002 mnt_id: 82 1924757 0 -r-------- 1 dan dan 0 Mar 2 10:57 fdinfo/37 pos: 517 flags: 0500002 mnt_id: 82
| | | | * | | | Merge tag 'mariadb-5.5.59' into 5.5-galeraJan Lindström2018-01-192-12/+3
| | | | |\ \ \ \
View Lorry Controller Status