Fixed incorrect handling of user credentials when authenticating
via proxy user. Now the server will use the proxies user's
access mask and host to update the security context runtime
structure when logging in.
Fixed a compilation warning with the embedded library.
Fixed a crash when doing a second GRANT PROXY on ''@'' due to
incomplete equality check logic.
The problem was that the x86 assembly based atomic CAS
(compare and swap) implementation could copy the wrong
value to the ebx register, where the cmpxchg8b expects
to see part of the "comparand" value. Since the original
value in the ebx register is saved in the stack (that is,
the push instruction causes the stack pointer to change),
a wrong offset could be used if the compiler decides to
put the source of the comparand value in the stack.
The solution is to copy the comparand value directly from
memory. Since the comparand value is 64-bits wide, it is
copied in two steps over to the ebx and ecx registers.
include/atomic/x86-gcc.h:
For reference, an excerpt from a faulty binary follows.
It is a disassembly of my_atomic-t, compiled at -O3 with
ICC 11.0. Most of the code deals with preparations for
a atomic cmpxchg8b operation. This instruction compares
the value in edx:eax with the destination operand. If the
values are equal, the value in ecx:ebx is stored in the
destination, otherwise the value in the destination operand
is copied into edx:eax.
In this case, my_atomic_add64 is implemented as a compare
and exchange. The addition is done over temporary storage
and loaded into the destination if the original term value
is still valid.
volatile int64 a64;
int64 b=0x1000200030004000LL;
a64=0;
mov 0xfffffda8(%ebx),%eax
xor %ebp,%ebp
mov %ebp,(%eax)
mov %ebp,0x4(%eax)
my_atomic_add64(&a64, b);
mov 0xfffffda8(%ebx),%ebp # Load address of a64
mov 0x0(%ebp),%edx # Copy value
mov 0x4(%ebp),%ecx
mov %edx,0xc(%esp) # Assign to tmp var in the stack
mov %ecx,0x10(%esp)
add $0x30004000,%edx # Sum values
adc $0x10002000,%ecx
mov %edx,0x8(%esp) # Save part of result for later
mov 0x0(%ebp),%esi # Copy value of a64 again
mov 0x4(%ebp),%edi
mov 0xc(%esp),%eax # Load the value of a64 used
mov 0x10(%esp),%edx # for comparison
mov %esi,(%esp)
mov %edi,0x4(%esp)
push %ebx # Push %ebx into stack. Changes esp.
mov 0x8(%esp),%ebx # Wrong restore of the result.
lock cmpxchg8b 0x0(%ebp)
sete %cl
pop %ebx
CHECKSUM TABLE for performance schema tables could cause uninitialized
memory reads.
The root cause is a design flaw in the implementation of
mysql_checksum_table(), which do not honor null fields.
However, fixing this bug in CHECKSUM TABLE is risky, as it can cause the
checksum value to change.
This fix implements a work around, to systematically reset fields values
even for null fields, so that the field memory representation is always
initialized with a known value.
Before this fix, the test output for perfschema.server_init would
vary between executions, because some of the objects tested were
not guaranteed to exist in all configurations / code paths.
This fix removes these weak tests.
Also, comments referring to abandonned code have been cleaned up.
tree for embedded server
Test case for bug #56251 "Deadlock with INSERT
DELAYED and MERGE tables" can't be run against
embedded server. Embedded server converts all
DELAYED INSERTs into ordinary INSERTs and this
test can't work properly if such conversion
happens.
Moved this test from merge.test to delayed.test
which is skipped if test suite is run with
--embedded-server option.
Subselect executes twice, at JOIN::optimize stage
and at JOIN::execute stage. At optimize stage
Innodb prebuilt struct which is used for the
retrieval of column values is initialized in.
ha_innobase::index_read(), prebuilt->sql_stat_start is true.
After QUICK_ROR_INTERSECT_SELECT finished his job it
restores read_set/write_set bitmaps with initial values
and deactivates one of the handlers used by
QUICK_ROR_INTERSECT_SELECT in JOIN::cleanup
(it's the case when we reuse original handler as one of
handlers required by QUICK_ROR_INTERSECT_SELECT object).
On second subselect execution inactive handler is activated
in QUICK_RANGE_SELECT::reset, file->ha_index_init().
In ha_index_init Innodb prebuilt struct is reinitialized
with inappropriate read_set/write_set bitmaps. Further
reinitialization in ha_innobase::index_read() does not
happen as prebuilt->sql_stat_start is false.
It leads to partial retrieval of required field values
and we get a mix of field values from different records
in the record buffer.
The fix is to reset
read_set/write_set bitmaps as these values
are required for proper intialization of
internal InnoDB struct which is used for
the retrieval of column values
(see build_template(), ha_innodb.cc)
mysql-test/include/index_merge_ror_cpk.inc:
test case
mysql-test/r/index_merge_innodb.result:
test case
mysql-test/r/index_merge_myisam.result:
test case
sql/opt_range.cc:
if ROR merge scan is used we need to reset
read_set/write_set bitmaps as these values
are required for proper intialization of
internal InnoDB struct which is used for
the retrieval of column values
(see build_template(), ha_innodb.cc)
adding new indexes
A fast alter table requires that the existing (old) table
and indices are unchanged (i.e only new indices can be
added). To verify this, the layout and flags of the old
table/indices are compared for equality with the new.
The PACK_KEYS option is a no-op in InnoDB, but the flag
exists, and is used in the table compare. We need to
check this (table) option flag before deciding whether an
index should be packed or not. If the table has
explicitly set PACK_KEYS to 0, the created indices should
not be marked as packed/packable.
