The error message "InnoDB: innodb_page_size=65536 requires innodb_buffer_pool_size >= 20MiB current 10MiB" is the relevant one.
The root cause:
mysql_install_db bootstraps with --innodb-buffer-pool-size=10M.
Small bufferpool is here by design - bootstrap should succeed,
even if there is not much RAM available, bootstrap does not need that much
memory.
For pagesize 64K specifically, Innodb thinks it needs a larger bufferpool,
and thus it lets the bootstrap process die (although the expected behavior
in this case would be to adjust value, give warning and continue)
The workaround:
- pass --innodb-buffer-pool-size=20M, which is suitable for all page sizes.
- check the same limit in MSI custom action.
Also, the patch adds mtr test for 64K page size.
This happens for example if one installs into home directory of a user
C:\Users\<username>\mariadb
The reason is that the service user "NT SERVICE\<service_name>" does
not have read and execute permissions for service executable mysqld.exe
in this directory.
Moreover, it would not have read permissions for server.dll loaded by the
exe, or to plugin directory, where plugins may reside.
The fix is to give service users read and execute permissions to bin, share, and
lib\plugin subdirectories.
The permission setting is doneby mysql_install_db.exe, but also in MSI.
It is important to do that in MSI, as we want permissions to survive
the MSI upgrade.
Two Problems
1. Upgrade wizard failed to retrieve path to service executable,
if it contained non-ASCII.
Fixed by setlocale(LC_ALL, "en_US.UTF8"), which was missing in upgrade wizard
2.mysql_upgrade_service only updated (converted to UTF8) the server's sections
leaving client's as-is
Corrected typo.
3. Fixed assertion in my_getopt, turns out to be too strict.
CreateServiceA, OpenServiceA, and couple of other functions do not work
correctly with non-ASCII character, in the special case where application
has defined activeCodePage=UTF8.
Workaround by redefining affected ANSI functions to own wrapper, which
works by converting narrow(ANSI) to wide, then calling wide function.
Deprecate original ANSI service functions, via declspec, so that we can catch
their use.
With this patch, 4-component MSI version can be used, e.g by setting
TINY_VERSION variable in CMake, or by adding a string, e.g
MYSQL_VERSION_EXTRA=-2
which sets TINY_VERSION to 2, and also changes the package name.
The 4-component MSI versions do not support MSI major upgrades, only minor
ones, i.e do not reinstall components, just update existing ones based
on versioning rules.
To support these rules, add DefaultVersion for the files that won't
otherwise be versioned - headers, static and import libraries,
pdbs, text - xml, python and perl scripts Also silence WiX warning
that MSI won't store hashes for those files anymore.
- set clone_depth to 1. Otherwise, appveyor spends
4.5 minutes for the "git clone" alone
- Use Ninja instead of msbuild, it is (a bit) faster
- do not compile perfschema, or dynamic plugins
to save time on compilation, or test execution.
- use -DFAST_BUILD=1 to speedup build a little
- increase number of parallel jobs used in build and test.
- Exclude some slow tests from the main suite.
The post-build custom command to embed Vista elevation manifest into
mariadb-upgrade-wizard.exe seems to do
something nasty to the executable, perhaps it removes and recreates it.
Thus the previously created hardlink mysql_upgrade_wizard is not marked
to require elevation.
Solved by using MANIFESTUAC linker flag, rather than invoke mt.exe.
This avoids an extra post-build step that modifies mariadb-upgrade-wizard.exe
