Fix two problems:
- The value of mysqli_get_client_info() has been changed recently and did
not include "mysqlnd" anymore thus the test suite was thinking the build
is always libmysql. This did not kept the suite from running pconn tests
- Going back to the libc allocator because the memory arena could be on a
persistent connections. If the build is not debug there will be no error
but the memory will be freed and in the second use of this pconn freed
memory will be used - not good! For now the arena doesn't take an argument
whether it should allocate persistently or not, thus persistent is safe
for now.
Johannes gave his +1 to commit this.
Memory usage optimisation. mysqlnd is not libmysql. mysqlnd does use the
Zend allocator, which means that is easier to hit memory_limit if you
have big stored (buffered) result sets. Before with libmysql you won't
hit memory_limit because libmysql uses libc's allocator and nothing is
checked. Now, with mysqlnd the situation is stricter and it is easier to
hit memory_limit. We try to optimize for big result sets. If a result set
is larger than 10 rows we will start freeing some data to keep memory usage
after 10 rows constant. This will help in the cases where a buffered result
set is scrolled forward only and just only once, or mysqlnd will need to
decode data from the network buffers again - yes, it is a trade-off between
CPU time and memory size. The best for big result sets is of course using
unbuffered queries - for comparison : 3 Million rows with buffered take
at least 180MB, with buffered you will stay at 3MB, and unbuffered will be
just 7-8% slower.
Hardwire function call instead of using callbacks. We don't actually need
callbacks, it was done for making 2 functions static, not to pollute the
global functions space but that had its price of 8 bytes overheat per
allocation, which is just too much. Also making the app member 32b instead
of 64b, which should save additional 4 byte, to the total of 12 byte per
allocation of a row buffer.
Fix crash when tracing is enabled. Position after buffer was used also
direct usage of MYSQLND_STRING pointer instead of the "s" property of the
structure.
some reason. Double free of the data, which led to valgrind warnigns.
The fix actually optimizes the code in this cases because the old code
used copy_ctor while the new one skips it because it is not needed.
Transferring data ownership and nulling works best, for PS where we
always copy the string from the result set, unlike the text protocol.
Fix a bug with mysqlnd_fetch_field(_direct()). With mysqlnd the optimised
function was called, which however, doesn't respect that during store the
raw data is not unpacked, to be lazy. The data is unpacked to zvals later,
during every row fetch. However, this way max_length won't be calculated
correctly. So, if a mysqlnd_fetch_field(_direct) call comes we need to
unpack everything and then calculate max_length...and that is expensive,
defies our lazy unpacking optimisation.
[DOC] This makes mysql_refresh() as described in
http://dev.mysql.com/doc/refman/6.0/en/mysql-refresh.html
available as mysqli_Refresh() and mysqli->refresh()
MYSQLI_REFRESH_BACKUP_LOG is only available when linking libmysql 6.0
or mysqlnd
Fix a small bug that mysqlnd::next_result didn't care about an error in a
multi-statement. In an inner layer the error has been already set, thus it
needed better massage on the top level.
Fix overusage of memory when the result set is empty. Then no memory will be
allocated compared to before. Also grow (realloc) the rset with 10% instead
of 33% - more reallocs but better memory usage. Of course later theres is a
realloc to shrink the rset t ofree it from unused rows but its better to
to eat too much at once.