Commit graph

64544 commits

Author SHA1 Message Date
Akhila Maddukuri
39739a423f Description:
-----------
After compiling from source, during make test I got the following error:

test main.loaddata failed with error
CURRENT_TEST: main.loaddata
mysqltest: At line 592: query 'LOAD DATA INFILE 'tmpp.txt' INTO TABLE t1
CHARACTER SET ucs2
(@b) SET a=REVERSE(@b)' failed: 1115: Unknown character set: 'ucs2'

I noticed other tests are skipped because of no ucs2
main.mix2_myisam_ucs2                    [ skipped ]  Test requires:'
have_ucs2'

Should main.loaddata be skipped if there is no ucs2

How To Repeat:
-------------
Run make test on compiled source that doesn't have ucs2

Suggested fix:
-------------
the failing piece of the test should be moved from mysql-test/t/loaddata.test to
mysql-test/t/ctype_ucs.test.
2012-09-26 16:38:42 +05:30
Tor Didriksen
abdb79062e Backport
Bug #11764313 57135: CRASH IN ITEM_FUNC_CASE::FIND_ITEM WITH CASE WHEN
Bug #11764818 57692: Crash in item_func_in::val_int() with ZEROFILL
2012-09-25 16:03:05 +02:00
mysql-builder@oracle.com
862fc0f51a 2012-09-25 18:44:21 +05:30
mysql-builder@oracle.com
0a50d49c5d 2012-09-25 18:00:26 +05:30
Jon Olav Hauglid
139c8ed591 Bug#14621627 THREAD CACHE IS UNFAIR
When a client connects to a MySQL server, first a THD object is created.
If there are any idle server threads waiting, the THD object is then added
to a list and a server thread is woken up. This thread then retrieves the 
THD object from the list and starts executing.

The problem was that this list of THD objects waiting for a server thread,
was not working in a FIFO fashion, but rather LIFO. This is unfair, as it means
that the last THD added (=last client connected) will be assigned a  server 
thread first.

Note however that for this to be a problem, several clients must be able
to connect and have THD objects constructed before any server threads
manages to be woken up. This is not a very likely scenario.

This patch fixes the problem by changing the THD list to work FIFO
rather than LIFO.

This is the 5.1/5.5 version of the patch.
2012-09-25 13:09:53 +02:00
Raghav Kapoor
5c089b0874 BUG#13864642: DROP/CREATE USER BEHAVING ODDLY
BACKGROUND:
In certain situations DROP USER fails to remove all privileges
belonging to user being dropped from in-memory structures.
Current workaround is to do DROP USER twice in scenario below
OR doing FLUSH PRIVILEGES after doing DROP USER.

ANALYSIS:
In MySQL, When we grant some stored routines privileges to a
user they are stored in their respective hash.
When doing DROP USER all the stored routine privilege entries
associated with that user has to be deleted from its respective 
hash.
The root cause for this bug is some entries from the hash
are not getting deleted. 
The problem is that code that deletes entries from the hash tries
to do so while iterating over it, without taking enough measures
to address the fact that such deletion can reshuffle elements in 
the hash. If the user/administrator creates the same user again 
he is thrown an  error 'Error 1396 ER_CANNOT_USER' from MySQL.
This prompts the user to either do FLUSH PRIVILEGES or do DROP USER 
again. This behaviour is not desirable as it is a workaround and
does not solves the problem mentioned above.

FIX:
This bug is fixed by introducing a dynamic array to store the 
pointersto all stored routine privilege objects that either have
to be deleted or updated. This is done in 3 steps.
Step 1: Fetching the element from the hash and checking whether 
it is to be deleted or updated.
Step 2: Storing the pointer to that privilege object in dynamic array.
Step 3: Traversing the dynamic array to perform the appropriate action 
either delete or update.
This is a much cleaner way to delete or update the privilege entries 
associated with some user and solves the problem mentioned above.
Also the code has been refactored a bit by introducing an enum
instead of hard coded numbers used for respective dynamic arrays 
and hashes in handle_grant_struct() function.
2012-09-25 15:58:46 +05:30
Rohit Kalhans
6d0574d306 BUG#14548159: Followup patch to fix some issues on PB2 2012-09-23 15:45:22 +05:30
Rohit Kalhans
5f003eca00 BUG#14548159: NUMEROUS CASES OF INCORRECT IDENTIFIER
QUOTING IN REPLICATION 

Problem: Misquoting or unquoted identifiers may lead to
incorrect statements to be logged to the binary log.

Fix: we use specialized functions to append quoted identifiers in
the statements generated by the server.
2012-09-22 17:50:51 +05:30
Nirbhay Choubey
600aa420d6 Bug#14645196 MYSQL CLIENT'S USE COMMAND FAILS
WHEN DBNAME CONTAINS MULTIPLE QUOTES

MySQL client's USE command might fail if the
database name contains multiple quotes (backticks).

The reason behind the failure being the method
that client uses to remove/escape the quotes
while parsing the USE command's option (dbname),
where the option parsing might terminate if a
matching quote is found.

Also, C-APIs like mysql_select_db() expect a
normalized dbname. Now, in certain cases, client
might fail to normalize dbname similar to that of
server and hence mysql_select_db() would fail.

Fixed by getting the normalized dbname (indirectly)
from the server by directly sending the "USE dbanme"
as query to the server followed by a "SELECT DATABASE()".
The above steps are only performed if number of quotes
in the dbname is greater than 2. Once the normalized
dbname is received, the original db is restored.
2012-09-21 23:28:55 +05:30
mysql-builder@oracle.com
91d6d38e70 2012-09-20 12:31:26 +03:00
Marko Mäkelä
aed6b87145 Bug#14636528 INNODB CHANGE BUFFERING IS NOT ENTIRELY CRASH-SAFE
Delete-mark change buffer records when resorting to a pessimistic
delete from the change buffer B-tree. Skip delete-marked records in
the change buffer merge and when estimating whether an operation can
be buffered. Without this fix, we could try to apply the same buffered
changes multiple times if the server was killed at the right moment.

In MySQL 5.5 and later: ibuf_get_volume_buffered_count_func(): Ignore
delete-marked (already processed) records.

ibuf_delete_rec(): Add a crash point before optimistic delete. If the
optimistic delete fails, flag the record processed before
mtr_commit().

ibuf_merge_or_delete_for_page(): Ignore delete-marked (already
processed) records.

Backport to 5.1: Rename btr_cur_del_unmark_for_ibuf() to
btr_cur_set_deleted_flag_for_ibuf() and add a parameter.

rb:1307 approved by Jimmy Yang
2012-09-19 22:35:38 +03:00
Marko Mäkelä
bb57fd74d0 Merge mysql-5.1 to working copy. 2012-09-17 15:07:09 +03:00
Harin Vadodaria
9f0727804c Bug#11753779: MAX_CONNECT_ERRORS WORKS ONLY WHEN 1ST
INC_HOST_ERRORS() IS CALLED.

Issue       : Sequence of calling inc_host_errors()
              and reset_host_errors() required some
              changes in order to maintain correct
              connection error count.

Solution    : Call to reset_host_errors() is shifted
              to a location after which no calls to
              inc_host_errors() are made.
2012-09-17 17:02:17 +05:30
Marko Mäkelä
dc80dcac40 Bug#12701488 ASSERT PAGE_ZIP_VALIDATE, UNIV_ZIP_DEBUG
page_zip_validate(), page_zip_validate_low(): Add a parameter for the
B-tree index.

page_zip_validate_low(): If the page contents does not match, check
that the record link chains match. Furthermore, if dict_index_t is
passed, check that the records match. (This reduces coverage a bit: if
index=NULL, we will ignore differences in record contents, that is,
the page payload.)

rb:1264 approved by Inaam Rana
2012-09-17 14:21:00 +03:00
Sujatha Sivakumar
4bfeb52d92 Bug#11750014:ASSERTION TRX_DATA->EMPTY() IN BINLOG_CLOSE_CONNECTION
Problem:
=======

trx_data->empty() assert happens at `binlog_close_connection'

Analysis:
========

trx_data->empty() function checks for no pending events
and the transaction cache to be empty.This function returns
"true" if no pending events are present and cache is empty.
Otherwise it returns false. `binlog_close_connection' call
expects the above function to return true. But if the
return value is false then assert is raised.

This bug was reproducible in a diskfull scenario. In this
disk full scenario try to do an insert operation so that
a new pending event is created and flushing this pending
event fails. Due to this failure the server goes down
and invokes `binlog_close_connection' for clean closure.
Since the pending event still remains the assert is caused.
This assert is caused only in non transactional databases.


Fix:
===

In a disk full scenario when the insertion fails the
transaction is rolled back and `binlog_end_trans`
is called to flush the pending events. But flush operation
fails as the disk is full and the function simply returns
`1' without taking any action to delete the pending event.

This leaves the event to remain till the closure of
connection.  `delete pending' statement has been added to 
do the required clean up action.
2012-09-17 11:48:02 +05:30
mysql-builder@oracle.com
38a172da00 2012-09-12 15:08:44 +03:00
Tor Didriksen
06e4a9696b Backport Bug#13724099 2012-09-12 08:36:12 +02:00
Joerg Bruehe
c0a1b2c891 Backport this change from MySQL 5.5 to 5.1:
Bug #14181049: MYSQL_INSTALL_DB.PL CREATES EMPTY SYSTEM TABLES FOR MYSQL

  The script is different from what's used on unixes.
  It was not playing the table insertion script (mysql_system_tables_data.sql),
  although it was checking for the presence of this script.
  Fixed by re-enabling the lookup for this file and replaying it at bootstrap
  time. Note that on the Unixes "SELECT @@hostname" does return a fully qualified
  name, whereas on Windows it returns only a hostname.
  So by default we're filtering records in the mysql.user table until we ensure
  this is fixed.

The change was coded in 5.5 by Georgi Kodinov <Georgi.Kodinov@Oracle.com>
2012-09-11 20:56:22 +02:00
Joerg Bruehe
1b494494ed Spec file change to work around cast ulonglong -> int. 2012-09-11 12:47:32 +02:00
Andrei Elkin
95f6e19187 merge bug14597605 to the main repo. 2012-09-10 17:33:41 +03:00
Andrei Elkin
7d115e1c2b Bug#14597605 Issue with Null-value user on slave
An "orthographic" typo in User_var::set_deferred() was made in fixes for
bug@14275000. While editing the signature of the initial patch to remove
the only argument, the assigned value of the argument remained in the body ... 
to be successfully compiled (!) thanks to names coincidence:
the arg to User_var method and its member.

Fixed with correcting the typo.
2012-09-10 17:32:04 +03:00
akhil.mohan@oracle.com
acb8b7d3e5 Raise version number after cloning 5.1.66 2012-09-07 10:30:53 +02:00
Tor Didriksen
fe36ad9778 Bug#13734987 MEMORY LEAK WITH I_S/SHOW AND VIEWS WITH SUBQUERY
In fill_schema_table_by_open(): free item list before restoring active arena.
2012-09-05 17:40:13 +02:00
mysql-builder@oracle.com
fc7e232a62 2012-09-03 11:33:05 +05:30
Annamalai Gurusami
4a3d325dc6 Bug #13453036 ERROR CODE 1118: ROW SIZE TOO LARGE - EVEN
THOUGH IT IS NOT.

The following error message is misleading because it claims 
that the BLOB space is not counted.  

"ERROR 1118 (42000): Row size too large. The maximum row size for 
the used table type, not counting BLOBs, is 8126. You have to 
change some columns to TEXT or BLOBs"

When the ROW_FORMAT=compact or ROW_FORMAT=REDUNDANT is used,
the BLOB prefix is stored inline along with the row.  So 
the above error message is changed as follows depending on
the row format used:

For ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, the error
message is as follows:

"ERROR 42000: Row size too large (> 8126). Changing some
columns to TEXT or BLOB may help. In current row format, 
BLOB prefix of 0 bytes is stored inline."

For ROW_FORMAT=COMPACT or ROW_FORMAT=REDUNDANT, the error
message is as follows:

"ERROR 42000: Row size too large (> 8126). Changing some
columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or 
ROW_FORMAT=COMPRESSED may help. In current row
format, BLOB prefix of 768 bytes is stored inline."

rb://1252 approved by Marko Makela
2012-08-31 15:42:00 +05:30
mysql-builder@oracle.com
c89780c0db 2012-08-31 09:51:27 +03:00
Marko Mäkelä
0303bc42d5 Bug#14554000 CRASH IN PAGE_REC_GET_NTH_CONST(NTH=0) DURING COMPRESSED
PAGE SPLIT

page_rec_get_nth_const(): Map nth==0 to the page infimum.

btr_compress(adjust=TRUE): Add a debug assertion for nth>0. The cursor
should never be positioned on the page infimum.

btr_index_page_validate(): Add test instrumentation for checking the
return values of page_rec_get_nth_const() during CHECK TABLE, and for
checking that the page directory slot 0 always contains only one
record, the predefined page infimum record.

page_cur_delete_rec(), page_delete_rec_list_end(): Add debug
assertions guarding against accessing the page slot 0.

page_copy_rec_list_start(): Clarify a comment about ret_pos==0.

rb:1248 approved by Jimmy Yang
2012-08-30 21:53:41 +03:00
Marko Mäkelä
22f264f3d3 Bug#14547952: DEBUG BUILD FAILS ASSERTION IN RECORDS_IN_RANGE()
ha_innodb::records_in_range(): Remove a debug assertion
that prohibits an open range (full table).

The patch by Jorgen Loland only removed the assertion from the
built-in InnoDB, not from the InnoDB Plugin.
2012-08-30 21:49:24 +03:00
Jorgen Loland
95b4747356 Bug#14547952: DEBUG BUILD FAILS ASSERTION IN RECORDS_IN_RANGE()
ha_innobase::records_in_range(): Remove a debug assertion
that prohibits an open range (full table).
This assertion catches unnecessary calls to this method, 
but such calls are not harming correctness.
2012-08-28 14:51:01 +02:00
Marko Mäkelä
634e094c06 Fix regression from Bug#12845774 OPTIMISTIC INSERT/UPDATE USES WRONG
HEURISTICS FOR COMPRESSED PAGE SIZE

The fix of Bug#12845774 was supposed to skip known-to-fail
btr_cur_optimistic_insert() calls. There was only one such call, in
btr_cur_pessimistic_update(). All other callers of
btr_cur_pessimistic_insert() would release and reacquire the B-tree
page latch before attempting the pessimistic insert. This would allow
other threads to restructure the B-tree, allowing (and requiring) the
insert to succeed as an optimistic (single-page) operation.

Failure to attempt an optimistic insert before a pessimistic one would
trigger an attempt to split an empty page.

rb:1234 approved by Sunny Bains
2012-08-21 10:47:17 +03:00
Mattias Jonsson
a0fd666041 Bug#13025132 - PARTITIONS USE TOO MUCH MEMORY
pre-push fix, removed unused variable.
2012-08-20 12:39:36 +02:00
Mattias Jonsson
a144799c05 merge 2012-08-20 11:18:17 +02:00
Mattias Jonsson
5abec3c287 Bug#13025132 - PARTITIONS USE TOO MUCH MEMORY
Additional patch to remove the part_id -> ref_buffer offset.

The partitioning id and the associate record buffer can
be found without having to calculate it.

By initializing it for each used partition, and then reuse
the key-buffer from the queue, it is not needed to have
such map.
2012-08-17 14:25:32 +02:00
Alexander Barkov
3fe9686201 Backporting Bug 14100466 from 5.6. 2012-08-17 13:14:04 +04:00
Marko Mäkelä
a5ddcaab74 Bug#12595091 POSSIBLY INVALID ASSERTION IN BTR_CUR_PESSIMISTIC_UPDATE()
Facebook got a case where the page compresses really well so that
btr_cur_optimistic_update() returns DB_UNDERFLOW, but when a record
gets updated, the compression rate radically changes so that
btr_cur_insert_if_possible() can not insert in place despite
reorganizing/recompressing the page, leading to the assertion failing.

rb:1220 approved by Sunny Bains
2012-08-16 17:45:39 +03:00
Marko Mäkelä
0a51eb41ce Bug#12845774 OPTIMISTIC INSERT/UPDATE USES WRONG HEURISTICS FOR
COMPRESSED PAGE SIZE

This was submitted as MySQL Bug 61456 and a patch provided by
Facebook. This patch follows the same idea, but instead of adding a
parameter to btr_cur_pessimistic_insert(), we simply remove the
btr_cur_optimistic_insert() call there and add it to the only caller
that needs it.

btr_cur_pessimistic_insert(): Do not try btr_cur_optimistic_insert().

btr_insert_on_non_leaf_level_func(): Invoke btr_cur_optimistic_insert()
before invoking btr_cur_pessimistic_insert().

btr_cur_pessimistic_update(): Clarify in a comment why it is not
necessary to invoke btr_cur_optimistic_insert().

btr_root_raise_and_insert(): Assert that the root page is not empty.
This could happen if a pessimistic insert (involving a split or merge)
is performed without first attempting an optimistic (intra-page) insert.

rb:1219 approved by Sunny Bains
2012-08-16 17:37:52 +03:00
Marko Mäkelä
9d620a851b Bug#13523839 ASSERTION FAILURES ON COMPRESSED INNODB TABLES
btr_cur_optimistic_insert(): Remove a bogus assertion. The insert may
fail after reorganizing the page.

btr_cur_optimistic_update(): Do not attempt to reorganize compressed pages,
because compression may fail after reorganization.

page_copy_rec_list_start(): Use page_rec_get_nth() to restore to the
ret_pos, which may also be the page infimum.

rb:1221
2012-08-16 17:31:23 +03:00
Mattias Jonsson
8c72fd8b78 Bug#13025132 - PARTITIONS USE TOO MUCH MEMORY
The buffer for the current read row from each partition
(m_ordered_rec_buffer) used for sorted reads was
allocated on open and freed when the ha_partition handler
was closed or destroyed.

For tables with many partitions and big records this could
take up too much valuable memory.

Solution is to only allocate the memory when it is needed
and free it when nolonger needed. I.e. allocate it in
index_init and free it in index_end (and to handle failures
also free it on reset, close etc.)

Also only allocating needed memory, according to
partitioning pruning.

Manually tested that it does not use as much memory and
releases it after queries.
2012-08-15 14:31:26 +02:00
Sujatha Sivakumar
c6d8569d41 Bug#13596613:SHOW SLAVE STATUS GIVES WRONG OUTPUT WITH
MASTER-MASTER AND USING SET USE

Problem:
=======
In a master-master set-up, a master can show a wrong
'SHOW SLAVE STATUS' output.

Requirements:
- master-master
- log_slave_updates

This is caused when using SET user-variables and then using
it to perform writes. From then on the master that performed
the insert will have a SHOW SLAVE STATUS that is wrong and  
it will never get updated until a write happens on the other
master. On"Master A" the "exec_master_log_pos" is not
getting updated.

Analysis:
========
Slave receives a "User_var" event from the master and after
applying the event, when "log_slave_updates" option is
enabled the slave tries to write this applied event into
its own binary log. At the time of writing this event the
slave should use the "originating server-id". But in the
above case the sever always logs the  "user var events"
by using its global server-id. Due to this in a
"master-master" replication when the event comes back to the
originating server the "User_var_event" doesn't get skipped.
"User_var_events" are context based events and they always
follow with a query event which marks their end of group.
Due to the above mentioned problem with "User_var_event"
logging the "User_var_event" never gets skipped where as
its corresponding "query_event" gets skipped. Hence the
"User_var" event always waits for the next "query event"
and the "Exec_master_log_position" does not get updated
properly.

Fix:
===
`MYSQL_BIN_LOG::write' function is used to write events
into binary log. Within this function a new object for
"User_var_log_event" is created and this new object is used
to write the "User_var" event in the binlog. "User var"
event is inherited from "Log_event". This "Log_event" has
different overloaded constructors. When a "THD" object
is present "Log_event(thd,...)" constructor should be used
to initialise the objects and in the absence of a valid
"THD" object "Log_event()" minimal constructor should be
used. In the above mentioned problem always default minimal
constructor was used which is incorrect. This minimal
constructor is replaced with "Log_event(thd,...)".
2012-08-14 14:11:01 +05:30
Venkata Sidagam
40319e9b44 Bug #13115401: -SSL-KEY VALUE IS NOT VALIDATED AND IT ALLOWS INSECURE
CONNECTIONS IF SPE

Problem description: -ssl-key value is not validated, you can assign any bogus 
text to --ssl-key and it is not verified that it exists, and more importantly, 
it allows the client to connect to mysqld.

Fix: Added proper validations checks for --ssl-key.

Note:
1) Documentation changes require for 5.1, 5.5, 5.6 and trunk in the sections
   listed below and the details are :

 http://dev.mysql.com/doc/refman/5.6/en/ssl-options.html#option_general_ssl
    and
 REQUIRE SSL section of
 http://dev.mysql.com/doc/refman/5.6/en/grant.html

2) Client having with option '--ssl', should able to get ssl connection. This 
will be implemented as part of separate fix in 5.6 and trunk.
2012-08-11 15:43:04 +05:30
Sergey Glukhov
af3fdefca5 Bug #14409015 MEMORY LEAK WHEN REFERENCING OUTER FIELD IN HAVING
When resolving outer fields, Item_field::fix_outer_fields()
creates new Item_refs for each execution of a prepared statement, so
these must be allocated in the runtime memroot. The memroot switching
before resolving JOIN::having causes these to be allocated in the
statement root, leaking memory for each PS execution.
2012-08-09 15:34:52 +04:00
Marko Mäkelä
7e7ba738a2 Merge from mysql-5.1 to working copy. 2012-08-09 10:48:25 +03:00
Marko Mäkelä
e0482cb0bc Bug#14399148 INNODB TABLES UNDER LOAD PRODUCE DUPLICATE COPIES OF ROWS
IN QUERIES

This bug was caused by an incorrect fix of
Bug#13807811 BTR_PCUR_RESTORE_POSITION() CAN SKIP A RECORD

There was nothing wrong with btr_pcur_restore_position(), but with the
use of it in the table scan during index creation.

rb:1206 approved by Jimmy Yang
2012-08-09 09:55:29 +03:00
Sunanda Menon
dd8a7a93bc Merge from mysql-5.1.65-release 2012-08-09 08:50:43 +02:00
Rohit Kalhans
941924e831 BUG#11757312: MYSQLBINLOG DOES NOT ACCEPT INPUT FROM STDIN
WHEN STDIN IS A PIPE
            
Problem: Mysqlbinlog does not accept the input from STDIN when 
STDIN is a pipe. This prevents the users from passing the input file
through a shell pipe.    

Background: The my_seek() function does not check if the file descriptor
passed to it is regular (seekable) file. The check_header() function in
mysqlbinlog calls the my_b_seek() unconditionally and it fails when
the underlying file is a PIPE.  
            
Resolution: We resolve this problem by checking if the underlying file
is a regular file by using my_fstat() before calling my_b_seek(). 
If the underlying file is not seekable we skip the call to my_b_seek()
in check_header().
2012-08-08 22:15:46 +05:30
Nirbhay Choubey
d4e4538b2d Bug#13928675 MYSQL CLIENT COPYRIGHT NOTICE MUST
SHOW 2012 INSTEAD OF 2011

* Added a new macro to hold the current year :
  COPYRIGHT_NOTICE_CURRENT_YEAR
* Modified ORACLE_WELCOME_COPYRIGHT_NOTICE macro
  to take the initial year as parameter and pick
  current year from the above mentioned macro.
2012-08-07 18:58:19 +05:30
Harin Vadodaria
a9acf42bb0 Bug#14068244: INCOMPATIBILITY BETWEEN LIBMYSQLCLIENT/LIBMYSQLCLIENT_R
AND LIBCRYPTO

Problem: libmysqlclient_r exports symbols from yaSSL library which
         conflict with openSSL symbols. This issue is related to symbols
         used by CURL library and are defined in taocrypt. Taocrypt has
         dummy implementation of these functions. Due to this when a
         program which uses libcurl library functions is compiled using
         libmysqlclient_r and libcurl, it hits segmentation fault in
         execution phase.

Solution: MySQL should not be exporting such symbols. However, these
          functions are not used by MySQL code at all. So avoid compiling
          them in the first place.
2012-08-07 16:23:53 +05:30
Chaithra Gopalareddy
00fff1e12e Bug #14099846: EXPORT_SET CRASHES DUE TO OVERALLOCATION OF MEMORY
Backport the fix from 5.6 to 5.1
Base bug number : 11765562
2012-08-05 16:29:28 +05:30
Joerg Bruehe
e00f8f7f3b INSTALL-BINARY placeholder: change invalid URLs (request from Kristofer) 2012-07-31 20:41:46 +02:00
Tor Didriksen
611484f9a5 Bug#14111180 HANDLE_FATAL_SIGNAL IN PTR_COMPARE_1 / QUEUE_INSERT
Space available for merging was calculated incorrectly.
2012-07-27 09:13:10 +02:00