Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2686)
Sergei Golubchik ser...@pisem.net writes:
=== modified file 'dbug/dbug.c'
--- a/dbug/dbug.c2009-03-12 22:27:35 +
+++ b/dbug/dbug.c2009-03-18 14:08:05 +
@@ -506,6 +506,7 @@ int DbugParse(CODE_STATE *cs, const char
rel= control[0] == '+' || control[0] == '-';
if ((!rel || (!stack-out_file !stack-next)))
{
+FreeState(cs, stack, 0);
you may be freeing uuninitialized data here.
Ok, that's not good, obviously.
What are you trying to fix anyway ?
The leak from this Valgrind warning:
==28234== 51 bytes in 1 blocks are definitely lost in loss record 3 of 7
==28234==at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
==28234==by 0xAA3452: DbugMalloc (dbug.c:2164)
==28234==by 0xAA2864: ListAddDel (dbug.c:1489)
==28234==by 0xAA009E: DbugParse (dbug.c:572)
==28234==by 0xAA0A27: _db_set_init_ (dbug.c:913)
==28234==by 0x66C4C3: mysqld_get_one_option (mysqld.cc:7942)
==28234==by 0xA89E5C: handle_options (my_getopt.c:530)
==28234==by 0x6720C4: get_options(int*, char**) (mysqld.cc:8524)
==28234==by 0x672590: init_common_variables(char const*, int, char**, char
const**) (mysqld.cc:3312)
==28234==by 0x673EAB: main (mysqld.cc:4318)
If I remember correctly, it is init_settings.keywords that is not de-allocated
correctly when DbugParse is called multiple times.
Due to BUG#43418, mysql-test-run was not detecting all Valgrind warnings. And
after I fixed that bug, a number of additional warnings surfaced, this on
included.
If you have a better suggestion for silencing this leak, that would be
great. Otherwise I need to look a bit deeper, I admit I did not properly check
for the possibility of freeing uninitialised pointers.
@@ -1648,10 +1649,12 @@ static void FreeState(CODE_STATE *cs, st
FreeList(state-processes);
if (!is_shared(state, p_functions))
FreeList(state-p_functions);
- if (!is_shared(state, out_file))
+ if (!is_shared(state, out_file)
+ state-out_file != stderr state-out_file != stdout)
DBUGCloseFile(cs, state-out_file);
(void) fflush(cs-stack-out_file);
- if (state-prof_file)
+ if (state-prof_file
+ state-out_file != stderr state-out_file != stdout)
typo. you obviously want s/out_file/prof_file/g
Well spotted!
Thanks a lot, Sergei!
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB and Windows
Patrick Crews glee...@gmail.com writes: I was wondering what is the policy / direction for MariaDB and Windows. Basically, are we aiming to maintain MariaDB for that platform as well? The current plan is to keep MariaDB working on Windows. net_serv.cc C:\work\maria\include\violite.h(91) : error C2146: syntax error : missing ';' before identifier 'vio_pending' C:\work\maria\include\violite.h(91) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int C:\work\maria\include\violite.h(91) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int This looks to be due to a missing ssize_t definition. From a quick web search, ssize_t seems to be a Linux-ism, or at least not in the ANSI C standard. You should probably add a windows definition, maybe typedef ptrdiff_t ssize_t .\mysqltest.cc(1638) : warning C4244: 'argument' : conversion from 'my_off_t' to 'size_t', possible loss of data .\mysqltest.cc(1639) : warning C4244: 'argument' : conversion from 'my_off_t' to 'size_t', possible loss of data .\mysqltest.cc(1642) : warning C4244: '=' : conversion from 'my_off_t' to 'size_t', possible loss of data .\mysqltest.cc(1643) : warning C4244: '=' : conversion from 'my_off_t' to 'size_t', possible loss of data .\mysqltest.cc(1647) : warning C4244: 'argument' : conversion from 'my_off_t' to 'size_t', possible loss of data .\mysqltest.cc(1649) : warning C4244: 'argument' : conversion from 'my_off_t' to 'size_t', possible loss of data .\mysqltest.cc(1654) : warning C4244: 'argument' : conversion from 'my_off_t' to 'size_t', possible loss of data Are these warnings also in MySQL source? I would think so, don't look fatal from a quick glance. Building Custom Rule C:/work/maria/unittest/mysys/CMakeLists.txt -- Configuring done -- Generating done -- Build files have been written to: C:/work/maria Compiling... waiting_threads-t.c .\waiting_threads-t.c(265) : warning C4013: 'ftruncate' undefined; assuming extern returning int Linking... waiting_threads-t.obj : error LNK2019: unresolved external symbol _ftruncate referenced in function _do_tests I guess Windows doesn't have ftruncate. Maybe there is a mysys portable replacement that you can use, or maybe you can wrap that part of the unit test in #ifdef HAVE_FTRUNCATE. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Launchpad repoistories upgraded, bzr version 1.9 now required
This morning I finished upgrading our three maria repositories at launchpad to repository format 1.9: lp:maria lp:maria/5.2 lp:maria/6.0 There should be no need to re-branch from launchpad or make any other changes to local trees or branches. However, I believe it will now be necessary to use bzr of at least version 1.9 to access the repositories on launchpad. It is recommended, but not required, to upgrade local shared repositores and branches with bzr upgrade --1.9 to get the following benefits 1. Stacked branches, which allows pushing private clones to lp:~USER/maria/xxx with only having to upload changes to main trees, for me pushing such a private branch now takes only ~30 seconds. 2. General faster operation of bzr in my experience (eg bzr log 10x faster). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] XtraDB commit
Vadim Tkachenko va...@percona.com writes: Ok, Got it. While mysql_plugin is not available is it OK if I send changeset for review manually ? Though it is rather big, as there a lot of changes InnoDB - InnoDB plugin. I think that is fine, please do. Though if it is bigger than 10 Mb or so it may be rejected by some mail systems. I may push to another three and propose for merge, in this case you also will be able to review changeset. Feel free to do this as well. We are not really using the Launchpad model of pushing to own branch and make merge request. But it would be good to get some experience with it in case it could work better for us. Though it seems to not produce diffs in the mails, which does not fit the current review model. It does make it much easier for people to try/use the code (as opposed to just the patch). If you upgrade your local bzr repository to version 1.9 (and use bzr 1.9 obviously), launchpad uses 'stacked branches', which means that when you push a new branch to launchpad it only has to transfer the new changeset. This makes creating new branches quite cheap (though xtradb may still take some bandwidth I assume ;-). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Merge] lp:~maria-captains/maria/maria-xtradb into lp:maria
Percona launch...@percona.com writes: Percona has proposed merging lp:~maria-captains/maria/maria-xtradb into lp:maria. Requested reviews: Maria-captains (maria-captains) Proposal to merge replacement InnoDB-XtraDB Thanks a lot for your efforts in this! I branched the tree and took a look. There are a couple of issues that I think need to be resolved before we can merge it into MariaDB. I have some questions below, but please don't hesitate to ask me for any kind of help needed to move this forward. === modified file 'storage/innobase/include/sync0rw.h' --- storage/innobase/include/sync0rw.h2008-02-19 16:44:09 + +++ storage/innobase/include/sync0rw.h2009-03-31 04:19:17 + +#ifndef INNODB_RW_LOCKS_USE_ATOMICS +#error INNODB_RW_LOCKS_USE_ATOMICS is not defined. Do you use enough new GCC or compatibles? +#error Or do you use exact options for CFLAGS? +#error e.g. (for x86_32): -m32 -march=i586 -mtune=i686 +#error e.g. (for Sparc_64): -m64 -mcpu=v9 +#error Otherwise, this build may be slower than normal version. +#endif + My attempt to build (BUILD/compile-pentium64-max) failed with this error. There were also other build errors (I assume places where the atomics-using code has not been extended with a part that works without the availability of atomics). The reason is that in the MariaDB tree, HAVE_GCC_ATOMIC_BUILTINS is disabled, which caused XtraDB to disable INNODB_RW_LOCKS_USE_ATOMICS, which triggers the above error. I think I understand why this makes sense for Percona, after all using these better synchronisation primitives is part of the reason for using the Percona server in the first place. Can you tell me if Percona has decided not to maintain XtraDB working without the availability of atomic operations? Or if it is just an oversight? I need to discuss with other MariaDB people whether XtraDB for MariaDB should be maintained working without the atomic operations (if so, we should of course be willing to do the work/effort required). So, any thoughts about the best way to deal with this? Should the above #error be removed and XtraDB extended to work without atomics in the MariaDB tree? And is this something Percona wants to do, or should I look into it? Also, Sergei Golubchik told me that HAVE_GCC_ATOMIC_BUILTINS is for my_atomic_ops, and InnoDB/XtraDB shouldn't really be using it. But I need to look more into the code to understand what the problem is, if any. === added directory 'storage/innobase/mysql-test' === added directory 'storage/innobase/mysql-test/patches' When I ran the test suite, I got test failures in test main.innodb. I see that the patch contains patches for main MySQL test cases in mysql-test/t/*.test, and also seems to add separate test cases in the storage/innobase/mysql-test/ directory. Do you know what the status is of these test suite modifications? Do the patches need to be applied to the existing test suite, and/or should the extra test cases be used to add to/overwrite the existing tests? We would need to get the test suite to run without problems before merging. Does Percona run the test suite with no failures? Can you suggest which directions I should work in to solve the test failures? Ie. I'm unsure to what extent the extra test cases/patches have already been applied in main MySQL sources, and whether failures are expected or are just due to not being adapted for current MariaDB source changes. Any help with the above would be great. I plan to continue working with you on this so we can get it merged without unnecessary delays. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Failures in mysql_client_test
Hi Igor, I have been trying to figure out the problems you see in the mysql_client_test test case in the MariaDB 5.1 tree. It has been tricky due to not being able to reproduce. Patrick Crews was able to reproduce though, and was helpful enough to file this bug with some additional info: https://bugs.launchpad.net/maria/+bug/363181 From this information, I pushed a few minor fixes to the Launchpad tree (two missing DBUG_RETURN statements). After this push, Patrick can no longer reproduce the failure. So, while my fixes were done in the area of the code where the problem seems to occur, I don't understand why two missing DBUG_RETURN would cause the error we saw... Maybe you can try again to see if you can reproduce the bug in the latest tree? If you cannot, then we may have to consider the problem fixed for now. If you can still reproduce, it would be very helpful if you could reproduce it with dbug enabled: perl mysql-test-run.pl --debug mysql_client_test and collect all the *.trace and *.err files from mysql-test/var/ and attach them to the bug or email them. It would be good to get progress on this annoying problem. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] compile issue and the -lz flag
Don Kehn dek...@gmail.com writes: when compiling on x64 systems (i.e. CentOS Fedora core 10) and using the BUILD/compile-pentium64-max, I'm getting the -lz error /usr/bin/ld: cannot find -lz and when I simplify the ./comfigure line to a --without-zlib it Hm, could not reproduce this locally. This was using BUILD/compile-pentium64-max on a 64-bit Ubuntu Hardy (amd64). works. So, after modifing the configure flags that results into: ./configure --prefix=/u02/local/mysql-5.1.34 --enable-assembler --with-extra-charsets=complex --enable-thread-safe-client --with-big-tables --with-readline --with-ssl --with-plugins=max --with-embedded-server --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static --without-zlib --enable-local-infile It still has problems with the -lz flag, so does anybody know what is bringing the -lz into the configure? Note: I've also tried --with-zlibdir=/usr/lib64, but same error. As far as I can tell, there is no --with-zlib, --without-zlib, or --with-zlibdir option in ./configure. The correct name of the option seems to be --with-zlib-dir. Just that ./configure has this 'nice' habbit of ignoring unknown options :-(. So probably you can get it to compile using --with-zlib-dir=bundled. However, by default (no --with-zlib-dir) option it should use the system libz if available, and fall back to bundled if not, as far as I can tell from sources. So it's strange that it failed for you. Can you show exact link error message? Maybe you have a broken or incompatible version of libz on your system? Do you have a zlib-dev package installed? - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] compile issue and the -lz flag
Don Kehn dek...@gmail.com writes: display.c:(.text+0x282): undefined reference to `tputs' This sounds like you are missing curses development libraries. On my machine (Ubuntu Hardy), I think they are in the package libncurses5-dev. Hopefully this will get you one step further. (Btw, on Ubuntu/Debian, a quick shortcut to get all required dependencies installed is the following: sudo apt-get build-dep mysql-server Maybe your system has something similar). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB + PBXT
Paul McCullagh paul.mccull...@primebase.org writes: I must say I find it strange that bzr is merging files with .OTHER and .BASE endings, because these are temp files which only occur after a merge conflict. My thinking is that these were accidentally added at some point in the history, and subsequently removed. And when merging this add+remove, we get the conflict because the parent directory does not exist in the merge destination. But I do not know for sure. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Bzr merge order
Kristian Nielsen kniel...@knielsen-hq.org writes:
Following up on this, I just learned about the bzr option
append_revisions_only that can be set on a branch.
Any opinions on this?
Having thought more on this, I really think we should enable
append_revisions_only.
There are many tools (and people as well) that depend on revision numbers and
have no knowledge about using revid: revision ids. And they often get confused
when a push changes the revision numbers of lots of recent commits.
Just two days ago on Tuesday, the merge of MySQL 5.1 changed the last 6
revision numbers or so, and this seems to have confused the Buildbot Bzr code
to the point where it choose to not build the new merge at all. (I have written
and installed a new method for Buildbot to detect pushes that hopefully solves
this problem. But I fear there are more places in the Buildbot code which
assumes revision numbers are simple numbers that can be compared meaningfully
to determine their ordering).
In any case, having simple revision numbers that correctly reflect the push
history is just so much nicer to work with, and this is something I really
missed with Bitkeeper and Pushbuild.
So unless there are objections, I want to implement this change early next
week. At most, developers will need to do an extra pull into a fresh clone of
main trees before pushing, if they forget this when merging up. And if needed,
we can probably ask Bzr developers to implement a simple --reverse or
--use-other-as-base option to make even this extra step unnecessary.
- Kristian.
This option can be used to enforce that the main history (sequence of
primary/left-hand parents from the tip) correctly reflects the series of
pushes into the public tree.
So assume this sequence of events:
1. Joe branches lp:maria (revision 1000), and starts hacking on a patch.
2. Other developers push revisions 1001, 1002, and 1003 to lp:maria.
3. Joe finishes the patch, the review is good. He runs `bzr merge lp:maria`,
followed by `bzr push lp:maria`.
As it is now, the resulting history of lp:maria will look like this:
1002 Joe (merge)
1000.1.3 | Other
1000.1.2 | developer's
1000.1.1 | commits
1001 Joe's patch
1000 Starting point
So it is not at all clear that the other commits were at some point pushed
individually to lp:maria. And if someone goes to look at revision 1002
thinking to see one of the other developer's commits, it will be missing (or
worse refer to the wrong commit after further pushes).
But if we set the append_revisions_only option on lp:maria, instead of this
Joe will get this error:
bzr: ERROR: Server sent an unexpected error: ('error', 'Operation denied
because it would change the main history, which is not permitted by the
append_revisions_only setting on branch
lp-139886317008592:///~knielsen/maria/tmp-buildbot-test.')
In this case, Joe will instead have to do this:
bzr branch lp:maria # or bzr pull lp:maria into an existing clean clone
bzr merge ../branch-with-patch
bzr commit -mmerged with trunk
bzr push lp:maria
Then the resulting history will be this:
1004 Joe (merge)
1000.1.1 Joe patch
1003 | Other
1002 | developer's
1001 | commits
1000 Starting point
Which is much nicer, IMHO.
So basically append_revisions_only enforces the merging style that I, Sanja,
and Monty already proposed as a good practise.
So I propose to add this option to the 5.1, 5.2, and 6.0 trees on
Launchpad. This will provide a clear record of the push history in the
repository, at the cost of enforcing the good practise merge style with one
extra bzr step.
Any opinions? Reasons not to do this?
If there is general agreement I will add the option (the process is somewhat
inconvenient, but I tested a procedure using sftp and that works ok).
(Incidentally, this way also makes it possible to correlate the branch history
directly with build history from Buildbot/Pushbuild, something I really missed
in the BitKeeper days).
- Kristian.
Kristian Nielsen kniel...@knielsen-hq.org writes:
I noticed a difference between Bitkeeper and Bzr merges.
In Bitkeeper, merge parents are essentially unordered. The two parents of a
merge are completely equal, and there is no way from the Bitkeeper to history
to say whether one parent was merged into the other or vise versa. The actual
order in which merge parents are listed is based on some deterministic
algorithm (most recent commit date if I recall correctly).
In particular, this means that in Bitkeeper, the result of a pull of A into B
is exactly identical to a pull of B into A. This makes it impossible to
establish the history of pushes into main trees from just the Bitkeeper
history.
In Bzr, merge parents _are_ ordered. Merging B into A gives a different
result
from merging A into B. When merging B into A (cd A; bzr merge B), A is the
primary or left-hand parent. The resulting tree has one extra top-level merge
revision
[Maria-developers] Query cache test failure in Buildbot for mariadb 5.1
Hi, There is a query cache related failure seen in Buildbot: https://askmonty.org/buildbot/builders/hardy-amd64-dbg/builds/35/steps/test/logs/stdio main.query_cache_28249 [ fail ] Test ended at 2009-05-21 09:13:10 CURRENT_TEST: main.query_cache_28249 --- /home/archivist/archivist-amd64/archivist-amd64/build/mysql-test/r/query_cache_28249.result 2009-05-21 09:30:15.0 +0300 +++ /home/archivist/archivist-amd64/archivist-amd64/build/mysql-test/r/query_cache_28249.reject 2009-05-21 11:13:10.0 +0300 @@ -46,7 +46,6 @@ 1 0 2 0 3 0 -4 0 RESET QUERY CACHE; SELECT *, (SELECT COUNT(*) FROM t2) FROM t1; a (SELECT COUNT(*) FROM t2) mysqltest: Result length mismatch - saving '/home/archivist/archivist-amd64/archivist-amd64/build/mysql-test/var/1/log/main.query_cache_28249/' to '/home/archivist/archivist-amd64/archivist-amd64/build/mysql-test/var/log/main.query_cache_28249/' Retrying test, attempt(2/3)... main.query_cache_28249 [ retry-pass ]509 Retrying test, attempt(3/3)... main.query_cache_28249 [ retry-pass ]404 I checked the bug: http://bugs.mysql.com/bug.php?id=28249 It is about a race condition in query cache and MyISAM (and re-test in Buildbot shows that it is not 100% reproducible). I am thinking that perhaps the bug was re-introduced with Maria, or in any case that someone more familiar with the MyISAM or Maria code would be better at looking into it. Any takers? - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Random test failure in main.show_check in mariadb 5.1 tree
There is another test failure visible in Buildbot: https://askmonty.org/buildbot/builders/gentoo-x86-dbg/builds/13/steps/test/logs/stdio --- main.show_check [ fail ] Test ended at 2009-05-22 11:47:11 CURRENT_TEST: main.show_check --- /home/buildbot/maria-slave/psergey-foxhole-x86/build/mysql-test/r/show_check.result 2009-05-22 09:56:56.0 +0300 +++ /home/buildbot/maria-slave/psergey-foxhole-x86/build/mysql-test/r/show_check.reject 2009-05-22 10:47:11.0 +0300 @@ -252,13 +252,13 @@ flush tables; show open tables; Database Table In_use Name_locked -mysql general_log 0 0 +mysql general_log 1 0 create table t1(n int); insert into t1 values (1); show open tables; Database Table In_use Name_locked -test t1 0 0 mysql general_log 0 0 +test t1 0 0 drop table t1; create table t1 (a int not null, b VARCHAR(10), INDEX (b) ) AVG_ROW_LENGTH=10 CHECKSUM=1 COMMENT=test ENGINE=MYISAM MIN_ROWS=10 MAX_ROWS=100 PACK_KEYS=1 DELAY_KEY_WRITE=1 ROW_FORMAT=fixed; show create table t1; mysqltest: Result content mismatch - saving '/home/buildbot/maria-slave/psergey-foxhole-x86/build/mysql-test/var/log/main.show_check/' to '/home/buildbot/maria-slave/psergey-foxhole-x86/build/mysql-test/var/log/main.show_check/' Retrying test, attempt(2/3)... main.show_check [ retry-pass ] 1421 Retrying test, attempt(3/3)... main.show_check [ retry-pass ] 1451 --- As can be seen, it is a random failure. Would be really great if someone could take a look and fix this. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Bzr merge order
Michael Widenius mo...@askmonty.org writes: K In this case, Joe will instead have to do this: K bzr branch lp:maria # or bzr pull lp:maria into an existing clean clone K bzr merge ../branch-with-patch K bzr commit -mmerged with trunk K bzr push lp:maria K Then the resulting history will be this: K 1004 Joe (merge) K 1000.1.1 Joe patch K 1003 | Other K 1002 | developer's K 1001 | commits K 1000 Starting point K Which is much nicer, IMHO. K So basically append_revisions_only enforces the merging style that I, Sanja, K and Monty already proposed as a good practise. K So I propose to add this option to the 5.1, 5.2, and 6.0 trees on K Launchpad. This will provide a clear record of the push history in the K repository, at the cost of enforcing the good practise merge style with one K extra bzr step. K Any opinions? Reasons not to do this? I like the end result of this approach, but I have got a couple of questions/concerns about this: - Doing the extra branch is a bit of a pain and slows down things if you pushes a lot. It would be nice to get this done internally in bzr as an part of the merge. Should we talk with canonical to get this option into bzr ? Yes, this is the main pain point. There are a couple of things that can help with this: 1. If bzr people were to implement `bzr pull --reverse`, then there would be no additional step, so problem would be solved (as long as one remembers to use the --reverse). The merge to be done is exactly the same one way or the other, the only difference is which tree becomes the primary parent and which becomes the secondary. 2. I suppose most people (like me) in any case keep a branch around of the main trees that we pull into regularly. This can be used to do the merge to avoid the need for an extra `bzr branch`. But then if someone else were to push to the main branch in-between, the clean local branch would have to be re-created of course. 3. I often use bzr with `bzr branch --no-tree` branches and seperate `bzr checkout --lightweight` working trees. This sometimes greatly speeds up operations when one can use `bzr switch` to avoid having to make bzr check out a complete working tree (which it does really slowly). But it has its own hassles also due to the need to keep track of more directories, so it is no silver bullet. With --lightweight checkouts, one can do something like this, all the steps of which run in a few seconds (on my machine at least): (cd ~/repo bzr branch --no-tree mariadb-5.1 mariadb-5.1-merge) bzr switch ~/repo/mariadb-5.1-merge bzr merge ~/repo/branch-with-patch # compile, test bzr push lp:maria - What is the sequence to do if someone does a push of this code at between the step 3) and step 4): 1)bzr branch lp:maria # or bzr pull lp:maria into an existing clean clone 2)bzr merge ../branch-with-patch 3)bzr commit -mmerged with trunk Someone else pushes here. 4) bzr push lp:maria Doing the 'merge' again would be a real pain. The issue is really the same no matter which of the two methods you use. If someone else pushes in-between, you need to merge again. I assume one should in this case start again from step 1) and do the merge with the new tree? Yes. One would need a new fresh branch of the now updated lp:maria tree, and merge into that. One could merge in either the original branch-with-patch or the branch with the first merge, depending on whatever works best (using the original will save a merge changeset, but the line of primary parent commits will be the same in the resulting push either way). K If there is general agreement I will add the option (the process is somewhat K inconvenient, but I tested a procedure using sftp and that works ok). I discussed this with Monty on IRC. I will implement it later this week in out Launchpad trees (and if there turns out to be unforseen problems with it, it will be easy enough to remove it again). Monty also will talk to Jani to get this method into autopush (in the autopush case this should be no extra hassle at all for the person pushing). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2706)
Daniel Bartholomew m...@daniel-bartholomew.com writes: Monty Agree. Until we get a maintiner, I assume Daniel can start looking at Monty these.o That would be great. I just pushed the imported files to lp:maria. for the Knowledgebase. Do you know if it is the installation instructions, the man pages, the help tables, or portions of all of them which are partly out of date? I do not know. However, I think it is safe to assume that they are all out of date to some degree at least. Probably the most important is to update the installation instructions to be up-to-date and refer properly to MariaDB rather than MySQL, as having these be wrong or inaccurate is quite confusing to users. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Please add into buildbot: lp:~maria-captains/maria-5.1-table-elimination
Sergey Petrunya pser...@askmonty.org writes: I've got a branch with the code for MWL#17. Could you please add it to what BuildBot builds? Done, it is running a test build now. I also documented the procedure for this on internal wiki: https://internal.askmonty.org/internal/index.php/BuildbotSetup#Launchpad_subscription (hm, wondering if I should put it on external wiki instead? But then adding a branch requires login on hasky, so maybe not.) - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Merge] lp:~qu1j0t3/maria/solaris10-port into lp:maria
Toby Thain t...@telegraphics.com.au writes: Toby Thain has proposed merging lp:~qu1j0t3/maria/solaris10-port into lp:maria. Added build scripts for 32 bit x86 architecture on Solaris. Renamed some scripts for consistency. Changed to dynamic linking of libgcc. -- https://code.launchpad.net/~qu1j0t3/maria/solaris10-port/+merge/6999 You are requested to review the proposed merge of lp:~qu1j0t3/maria/solaris10-port into lp:maria. === modified file 'BUILD/compile-solaris-amd64' --- BUILD/compile-solaris-amd64 2009-05-09 04:01:53 + +++ BUILD/compile-solaris-amd64 2009-06-02 22:10:57 + @@ -26,7 +26,7 @@ extra_flags=$amd64_cflags -D__sun -m64 -mtune=athlon64 extra_configs=$amd64_configs $max_configs --with-libevent -LDFLAGS=-lmtmalloc -static-libgcc +LDFLAGS=-lmtmalloc -R/usr/sfw/lib/64 export LDFLAGS . $path/FINISH.sh I'm basically ok with these changes. However, I would like you to add some explaining comments in the commit message about why the changes are done, especially the above regarding -static-libgcc and -R/usr/sfw/lib. Why are the changes needed, and what do they do? (generally it is more important in comments to explain _why_ than to explain _what_; the code already shows what happens, but not why.) Eg. if I had to merge these changes against conflicting changes from MySQL upstream, I would have no clue about what to do to resolve the conflict. You might also want to add some comments in the new script files for the Forte C options if any of them are of special importance, it is up to you really, you are the one who knows what they mean. - Kristian. -- https://code.launchpad.net/~qu1j0t3/maria/solaris10-port/+merge/6999 Your team Maria developers is subscribed to branch lp:maria. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Stab at C
Paul Charles Leddy pcle...@gmail.com writes: FYI, this really helped out getting started: http://drizzle.org/wiki/Contributing_Code Is there some way I can add something similar to maria's launchpad site? Any offer to help with this would certainly be most appreciated! I agree that something like this would be a an enourmous help. I modified your account on the askmonty.org wiki to have editor rights, so you can add the information you want. It would be good if you can confirm (just by email) that any text added would be available to Monty Program under a Creative Commons license (sorry for the legalese). I do not know if you need anything more to add what you want to the MariaDB Launchpad page, if you do just let me know. Thanks, - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Merge] lp:~maria-captains/maria/maria-xtradb into lp:maria
Kristian Nielsen kniel...@knielsen-hq.org writes: Just to avoid duplicate work, let me just mention that I am now starting to look into this issue. I will try to find a good way to make XtraDB compile/work on all the platforms/compilers we want to support, and report back what I discover. I got some good progress on this. I re-did the merge using the merge-into bzr plugin (advise from bzr developers). This should allow us to merge directly from the lp:percona-xtradb tree into lp:maria in the future. I placed the files in storage/xtradb/ and left storage/innodb/ in place. This should hopefully make merging from MySQL slightly easier, and seems to work well (and it is kind of nice also). I integrated the XtraDB testsuite into the tree so there is no need to run setup.sh or anything. I also fixed a number of test suite failures, and even a small bug or two. I fixed the code to compile without GCC atomic operation intrinsics. Performance will be worse of course, but it is good to have it at least working. I still need to fix Maria configure.in to not disable GCC atomics for xtradb by default. I pushed the result so far to Launchpad: lp:~maria-captains/maria/mariadb-xtradb-merge2 In particular you might be interested in the changeset 2702: http://bazaar.launchpad.net/~maria-captains/maria/mariadb-xtradb-merge2/revision/2702 Maybe you will want to merge some of that back into XtraDB? Comments are welcome, of course. I think that after fixing GCC atomics in configure this should be ready to push into MariaDB 5.1. Would be good to get a review of especially the 2702 commit. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Merge] lp:~maria-captains/maria/maria-xtradb into lp:maria
Kristian Nielsen kniel...@knielsen-hq.org writes: I got some good progress on this. I re-did the merge using the merge-into bzr plugin (advise from bzr developers). This should allow us to merge directly from the lp:percona-xtradb tree into lp:maria in the future. I just tested this, and it seems to work ok. I was able to merge latest XtraDB with just `bzr merge lp:parcona-xtradb`. And merging that into latest MariaDB also worked fine with just `bzr merge`. There were a number of conflicts in the merges. But I think that is only expected, and unavoidable in fact. Eg. when same problem was fixed in different ways in the different trees, or changes to InnoDB plugin files removed in MariaDB tree. Nothing serious, and we can reduce some of this by cooperating closely between XtraDB and MariaDB (and Sun and Oracle if they are willing). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2703)
Hi Serg,
We discussed something like this on IRC some time ago. What do you think of
this change? It keeps the use of GCC stuff for maria/my_atomic disabled, while
still letting other parts (ie. XtraDB) check for GCC intrinsics availability.
- Kristian.
kniel...@knielsen-hq.org writes:
#At lp:maria
2703 kniel...@knielsen-hq.org2009-06-10
Fix XtraDB to build with atomic operations, for good performance.
The root of the problem is that ./configure mixed together two
different things. One is the
availability of GCC atomic operation intrinsics. The other is the
selection of which
primitives to use for my_atomic implementation.
Then at some point a hack was made to not use GCC intrinsics in
my_atomic to work around
some test failures. But because the two things are mixed in
./configure, this as a side
effect also makes GCC intrinsics unavailable for XtraDB.
Fixed by splitting this in two in configure, so that we have
HAVE_GCC_ATOMIC_BUILTINS for
GCC intrinsics availability and MY_ATOMIC_MODE_GCC_BUILTINS for use in
my_atomic.
modified:
configure.in
include/atomic/nolock.h
=== modified file 'configure.in'
--- a/configure.in2009-04-23 13:06:16 +
+++ b/configure.in2009-06-10 09:13:53 +
@@ -1726,6 +1726,30 @@ then
fi
fi
+AC_CACHE_CHECK([whether the compiler provides atomic builtins],
+[mysql_cv_gcc_atomic_builtins], [AC_TRY_RUN([
+ int main()
+ {
+int foo= -10; int bar= 10;
+if (!__sync_fetch_and_add(foo, bar) || foo)
+ return -1;
+bar= __sync_lock_test_and_set(foo, bar);
+if (bar || foo != 10)
+ return -1;
+bar= __sync_val_compare_and_swap(bar, foo, 15);
+if (bar)
+ return -1;
+return 0;
+ }
+], [mysql_cv_gcc_atomic_builtins=yes],
+ [mysql_cv_gcc_atomic_builtins=no],
+ [mysql_cv_gcc_atomic_builtins=no])])
+
+if test x$mysql_cv_gcc_atomic_builtins = xyes; then
+ AC_DEFINE(HAVE_GCC_ATOMIC_BUILTINS, 1,
+ [Define to 1 if compiler provides atomic builtins.])
+fi
+
AC_ARG_WITH([atomic-ops],
AC_HELP_STRING([--with-atomic-ops=rwlocks|smp|up],
[Implement atomic operations using pthread rwlocks or atomic CPU
@@ -1739,28 +1763,9 @@ case $with_atomic_ops in
[Use pthread rwlocks for atomic ops]) ;;
smp) ;;
)
-AC_CACHE_CHECK([whether the compiler provides atomic builtins],
- [mysql_cv_gcc_atomic_builtins], [AC_TRY_RUN([
- int main()
- {
-int foo= -10; int bar= 10;
-if (!__sync_fetch_and_add(foo, bar) || foo)
- return -1;
-bar= __sync_lock_test_and_set(foo, bar);
-if (bar || foo != 10)
- return -1;
-bar= __sync_val_compare_and_swap(bar, foo, 15);
-if (bar)
- return -1;
-return 0;
- }
-], [mysql_cv_gcc_atomic_builtins=yes_but_disabled],
- [mysql_cv_gcc_atomic_builtins=no],
- [mysql_cv_gcc_atomic_builtins=no])])
-
-if test x$mysql_cv_gcc_atomic_builtins = xyes; then
- AC_DEFINE(HAVE_GCC_ATOMIC_BUILTINS, 1,
-[Define to 1 if compiler provides atomic builtins.])
+if test x$mysql_cv_gcc_atomic_builtins = xyes_but_disabled; then
+ AC_DEFINE([MY_ATOMIC_MODE_GCC_BUILTINS], [1],
+[Use GCC atomic builtins for atomic ops])
fi
;;
*) AC_MSG_ERROR([$with_atomic_ops is not a valid value for
--with-atomic-ops]) ;;
=== modified file 'include/atomic/nolock.h'
--- a/include/atomic/nolock.h 2008-02-05 15:47:11 +
+++ b/include/atomic/nolock.h 2009-06-10 09:13:53 +
@@ -14,7 +14,7 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#if defined(__i386__) || defined(_MSC_VER) || \
-defined(__x86_64__) || defined(HAVE_GCC_ATOMIC_BUILTINS)
+defined(__x86_64__) || defined(MY_ATOMIC_MODE_GCC_BUILTINS)
# ifdef MY_ATOMIC_MODE_DUMMY
#define LOCK_prefix
@@ -22,7 +22,7 @@
#define LOCK_prefix lock
# endif
-# ifdef HAVE_GCC_ATOMIC_BUILTINS
+# ifdef MY_ATOMIC_MODE_GCC_BUILTINS
#include gcc_builtins.h
# elif __GNUC__
#include x86-gcc.h
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2703)
Michael Widenius mo...@askmonty.org writes:
knielsen === modified file 'configure.in'
knielsen --- a/configure.in 2009-04-23 13:06:16 +
knielsen +++ b/configure.in 2009-06-10 09:13:53 +
knielsen @@ -1739,28 +1763,9 @@ case $with_atomic_ops in
knielsen[Use pthread rwlocks for atomic ops]) ;;
knielsensmp) ;;
knielsen)
knielsen -AC_CACHE_CHECK([whether the compiler provides atomic builtins],
knielsen - [mysql_cv_gcc_atomic_builtins], [AC_TRY_RUN([
knielsen - int main()
knielsen - {
knielsen -int foo= -10; int bar= 10;
knielsen -if (!__sync_fetch_and_add(foo, bar) || foo)
knielsen - return -1;
knielsen -bar= __sync_lock_test_and_set(foo, bar);
knielsen -if (bar || foo != 10)
knielsen - return -1;
knielsen -bar= __sync_val_compare_and_swap(bar, foo, 15);
knielsen -if (bar)
knielsen - return -1;
knielsen -return 0;
knielsen - }
knielsen -], [mysql_cv_gcc_atomic_builtins=yes_but_disabled],
knielsen - [mysql_cv_gcc_atomic_builtins=no],
knielsen - [mysql_cv_gcc_atomic_builtins=no])])
knielsen -
knielsen -if test x$mysql_cv_gcc_atomic_builtins = xyes; then
knielsen - AC_DEFINE(HAVE_GCC_ATOMIC_BUILTINS, 1,
knielsen -[Define to 1 if compiler provides atomic
builtins.])
knielsen +if test x$mysql_cv_gcc_atomic_builtins = xyes_but_disabled;
then
knielsen + AC_DEFINE([MY_ATOMIC_MODE_GCC_BUILTINS], [1],
knielsen +[Use GCC atomic builtins for atomic ops])
Under which circumstances could the last 'if' be true? The new code
don't seem to be able to set mysql_cv_gcc_atomic_builtins to
yes_but_disabled which makes the last if always false and we never
define MY_ATOMIC_MODE_GCC_BUILTINS as 1.
You are right that the if can never be true.
However, this is unchanged behaviour from before the patch, check the line with
[mysql_cv_gcc_atomic_builtins=yes_but_disabled] above.
Serg changed the yes to yes_but_disabled some time ago in the Maria
tree. This is a hack to disable the use of GCC intrinsics in my_atomic. Serg
told me that the reason is that there were failures in the unit tests when
using GCC intrinsics.
I did try to run unit tests with this hack removed, but I was not able to
repeat any failures. I do think we should remove the hack and instead fix the
real issue, if it is still there. However, I wanted to keep this separate from
the XtraDB merge, which is quite complicated enough without introducing
additional unrelated issues.
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2702)
Michael Widenius mo...@askmonty.org writes:
knielsen +/*
knielsen + We initialise the hashes for deadlock detection lazily.
knielsen + This greatly helps with performance when lots of mutexes are
initiased but
knielsen + only a few of them are actually used (eg. XtraDB).
knielsen +*/
knielsen +static int safe_mutex_lazy_init_deadlock_detection(safe_mutex_t
*mp)
knielsen +{
knielsen + if (!my_multi_malloc(MY_FAE | MY_WME,
knielsen + mp-locked_mutex,
sizeof(*mp-locked_mutex),
knielsen + mp-used_mutex, sizeof(*mp-used_mutex),
NullS))
knielsen + {
Add:
/* Disable deadlock handling for this mutex */
mp-flags|= MYF_NO_DEADLOCK_DETECTION;
Ok, done.
(It is not strictly necessary, as the caller checks the return value. The
difference is if in case of out-of-memory, the malloc() will be re-tried on
next access or not. It very likely doesn't matter one way or the other).
knielsen @@ -167,35 +196,8 @@ int safe_mutex_init(safe_mutex_t *mp,
knielsenmp-line= line;
knielsen/* Skip the very common '' prefix from the autogenerated name */
knielsenmp-name= name[0] == '' ? name + 1 : name;
knielsen + /* Deadlock detection is initialised only lazily, on first use.
*/
knielsen - if (safe_mutex_deadlock_detector !( my_flags
MYF_NO_DEADLOCK_DETECTION))
knielsen - {
knielsen -if (!my_multi_malloc(MY_FAE | MY_WME,
knielsen - mp-locked_mutex,
sizeof(*mp-locked_mutex),
knielsen - mp-used_mutex, sizeof(*mp-used_mutex),
NullS))
knielsen -{
knielsen - /* Disable deadlock handling for this mutex */
knielsen - my_flags|= MYF_NO_DEADLOCK_DETECTION;
knielsen -}
knielsen -else
knielsen -{
knielsen - pthread_mutex_lock(THR_LOCK_mutex);
knielsen - mp-id= ++safe_mutex_id;
knielsen - pthread_mutex_unlock(THR_LOCK_mutex);
knielsen - hash_init(mp-locked_mutex, my_charset_bin,
knielsen -1000,
knielsen -offsetof(safe_mutex_deadlock_t, id),
knielsen -sizeof(mp-id),
knielsen -0, 0, HASH_UNIQUE);
knielsen - hash_init(mp-used_mutex, my_charset_bin,
knielsen -1000,
knielsen -offsetof(safe_mutex_t, id),
knielsen -sizeof(mp-id),
knielsen -0, 0, HASH_UNIQUE);
knielsen -}
knielsen - }
knielsen - else
knielsen -my_flags|= MYF_NO_DEADLOCK_DETECTION;
You accidently removed checking of 'safe_mutex_deadlock_detector here.
Oops :-(
Fixed, thanks for catching this!
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] XtraDB merge into MariaDB
Regarding the XtraDB merge into MariaDB, I am now finally getting ready to push the merge, after lots of small fixes in different areas. The code is available in the mariadb-xtradb-merge2 branch: https://code.launchpad.net/~maria-captains/maria/mariadb-xtradb-merge2 The buildbot testing is here: https://askmonty.org/buildbot/waterfall?branch=mariadb-xtradb-merge2 Vadim, there is one remaining issue that I need Percona to look into. This is a hang in the innodb_xtradb_bug317074 test case on host hardy-amd64-dbg. Test output is included at the end of this mail, and full log is here: https://askmonty.org/buildbot/builders/hardy-amd64-dbg/builds/69/steps/test/logs/stdio Please take a look and see what it could be. The failure seems to be repeatable on that host. If needed, we can probably talk to archivist (who runs that build slave) on getting access to debug etc. I would also like your opinion on whether this is something that should block pushing the merge into MariaDB, as it is the last remaining known issue. Also, I was wondering if there is some way that Percona and MariaDB engineers could be on the same IRC channel(s)? That might be useful for some of the discussions. MariaDB engineers already hang out in #maria on FreeNode. Vadim Tkachenko va...@percona.com writes: I will look how we can backport your changes. We need to have xtradb compiled against standard 5.1, if it is not broken - it should be not problem to include your fixes. I am pretty sure there are no changes that would not work with 5.1. There are of course a number of changes that should _not_ go into the Percona XtraDB repository, like the replacing of innodb with xtradb etc. Here is an annotated list of the changes I think you should consider including upstream in XtraDB. If you choose to include any of them, it would be a help if you can do them in one (or a few) separate commits without any other changes. This will allow a simple null-merge to deal with merge conflits in any following xtradb-mariadb merges. Revision: 2716 http://bazaar.launchpad.net/~maria-captains/maria/mariadb-xtradb-merge2/revision/2716 The fix in mysql-test/t/innodb_information_schema.test would be relevant to merge into XtraDB. Revision: 2714 http://bazaar.launchpad.net/~maria-captains/maria/mariadb-xtradb-merge2/revision/2714 Here the test case fixes may be relevant. And there is a bug fix for ALTER TABLE in ha_innodb.cc ha_innobase::check_if_incompatible_data() that is needed to work with latest MySQL 5.1 sources (should also be ok with older 5.1 versions). There are also a few minor merges of changes from MySQL 5.1 to innodb not in the innodb plugin, which may or may not make sense for XtraDB to merge (probably doesn't matter). Revision: 2697.3.4 http://bazaar.launchpad.net/~maria-captains/maria/mariadb-xtradb-merge2/revision/2697.3.4 This is fixes for test suite failures. I think most are not relevant, however changes to these files fixes a test failure: mysql-test/t/innodb-zip.test mysql-test/r/innodb-zip.result As far as I can tell, remaining changes are either outside the innobase storage engine code (so cannot be meaningfully merged into XtraDB), or fixes mainly relevant for the merge into MariaDB. - Kristian. --- main.innodb_xtradb_bug317074 [ fail ] timeout after 900 seconds Test ended at 2009-06-23 15:20:52 Test case timeout after 900 seconds == /home/archivist/archivist-amd64/archivist-amd64/build/mysql-test/var/1/log/innodb_xtradb_bug317074.log == SET @save_innodb_file_format=@@global.innodb_file_format; SET @save_innodb_file_format_check=@@global.innodb_file_format_check; SET @save_innodb_file_per_table=@@global.innodb_file_per_table; SET GLOBAL innodb_file_format='Barracuda'; SET GLOBAL innodb_file_per_table=ON; == /home/archivist/archivist-amd64/archivist-amd64/build/mysql-test/var/1/tmp/analyze-timeout-mysqld.1.err == mysqltest: Could not open connection 'default' after 500 attempts: 2002 Can't connect to local MySQL server through socket '/home/archivist/archivist-amd64/archivist-amd64/build/mysql-test/var/tmp/1/mysqld.1.sock' (111) - saving '/home/archivist/archivist-amd64/archivist-amd64/build/mysql-test/var/1/log/main.innodb_xtradb_bug317074/' to '/home/archivist/archivist-amd64/archivist-amd64/build/mysql-test/var/log/main.innodb_xtradb_bug317074/' - found 'core.21388' (0/5) Trying 'dbx' to get a backtrace Trying 'gdb' to get a backtrace Core generated by '/home/archivist/archivist-amd64/archivist-amd64/build/sql/mysqld' Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). -- warning: Can't read pathname for load map: Input/output error. Core was generated by
Re: [Maria-developers] [Merge] lp:~qu1j0t3/maria/solaris10-port into lp:maria
Hi Toby, Toby Thain t...@telegraphics.com.au writes: On 3-Jun-09, at 12:48 PM, Kristian Nielsen wrote: Toby Thain t...@telegraphics.com.au writes: Toby Thain has proposed merging lp:~qu1j0t3/maria/solaris10-port into lp:maria. Added build scripts for 32 bit x86 architecture on Solaris. Renamed some scripts for consistency. Changed to dynamic linking of libgcc. I'm basically ok with these changes. However, I would like you to add some explaining comments in the commit message about why the changes are done, especially the above regarding The -static-libgcc was a legacy of the original build scripts. -R (analogous to -L link time search path) is a Solaris mechanism to ensure a needed lib directory is searched at runtime. cut I'm sorry that this has been stalling. I have now re-committed your changes with a more verbose commit message that includes some of your explanations in the email. I have pushed the result to lp:maria (no code changes compared to your branch). Thanks for your efforts with this, and sorry for the delay. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] XtraDB merge into MariaDB
Vadim Tkachenko va...@percona.com writes:
Kristian,
Now lp:percona-xtradb/release-6 and lp:percona-xtradb
should be synchronized and be up-to-date.
I still do not see that this is the case :-(
- Last push to lp:percona-xtradb is from June 26, and does not appear
up-to-date with latest XtraDB6 release.
- lp:percona-xtradb/release-6 does not exist. Maybe a typo for
lp:~percona-dev/percona-xtradb/release-6 ?
- I diffed lp:~percona-dev/percona-xtradb/release-6 against the XtraDB source
tarball on http://www.percona.com/mysql/xtradb/5.1.36-6/source/. They do
not match. The bzr branch is missing two bug fixes, on the other hand the
tarball has #define PERCONA_INNODB_VERSION 5a which seems to be wrong (diff
appended at the end of the mail).
Ok. To proceed, I have now committed the two missing bugfixes and pushed here:
lp:~maria-captains/percona-xtradb/release-6-fixed
I will use this as the basis for my merge. Maybe you can pull that into
lp:~percona-dev/percona-xtradb/release-6, or I will handle the conflict if
necessary in the next merge (should be no problem).
Please let me know if there something else from our side.
Only that I feel a bit stupid having these difficulties finding out what tree
to merge. Seems to me there is something I do not understand correctly... is
there some mailing list or IRC channel or something I should follow to better
keep track of XtraDB development?
- Kristian.
---
$ diff -u --recursive . ../mysql-5.1.36-xtradb6/storage/innobase
Only in .: .bzr
diff -u --recursive ./dict/dict0dict.c
../mysql-5.1.36-xtradb6/storage/innobase/dict/dict0dict.c
--- ./dict/dict0dict.c 2009-08-03 08:30:02.0 +0200
+++ ../mysql-5.1.36-xtradb6/storage/innobase/dict/dict0dict.c 2009-07-22
20:07:56.0 +0200
@@ -3049,7 +3049,7 @@
} else if (quote) {
/* Within quotes: do not look for
starting quotes or comments. */
- } else if (*sptr == '' || *sptr == '`') {
+ } else if (*sptr == '' || *sptr == '`' || *sptr == '\'') {
/* Starting quote: remember the quote character. */
quote = *sptr;
} else if (*sptr == '#'
diff -u --recursive ./handler/ha_innodb.cc
../mysql-5.1.36-xtradb6/storage/innobase/handler/ha_innodb.cc
--- ./handler/ha_innodb.cc 2009-08-03 08:30:02.0 +0200
+++ ../mysql-5.1.36-xtradb6/storage/innobase/handler/ha_innodb.cc
2009-07-22 20:07:56.0 +0200
@@ -9319,7 +9319,8 @@
/* Check that row format didn't change */
if ((info-used_fields HA_CREATE_USED_ROW_FORMAT)
- get_row_type() != info-row_type) {
+ get_row_type() != ((info-row_type == ROW_TYPE_DEFAULT)
+ ? ROW_TYPE_COMPACT : info-row_type)) {
return(COMPATIBLE_DATA_NO);
}
Only in ../mysql-5.1.36-xtradb6/storage/innobase/handler: ha_innodb.cc.orig
Only in ../mysql-5.1.36-xtradb6/storage/innobase/handler:
innodb_patch_info.h.orig
Only in ../mysql-5.1.36-xtradb6/storage/innobase/handler: i_s.cc.orig
diff -u --recursive ./include/univ.i
../mysql-5.1.36-xtradb6/storage/innobase/include/univ.i
--- ./include/univ.i2009-08-03 08:30:02.0 +0200
+++ ../mysql-5.1.36-xtradb6/storage/innobase/include/univ.i 2009-07-22
20:07:56.0 +0200
@@ -35,7 +35,7 @@
#define INNODB_VERSION_MAJOR 1
#define INNODB_VERSION_MINOR 0
#define INNODB_VERSION_BUGFIX 3
-#define PERCONA_INNODB_VERSION 6a
+#define PERCONA_INNODB_VERSION 5a
/* The following is the InnoDB version as shown in
SELECT plugin_version FROM information_schema.plugins;
Only in ./mysql-test/patches: mysqlbinlog_row_big.diff
Only in ./mysql-test/patches: variables-big.diff
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Federated code - IRC message
Michael Widenius mo...@askmonty.org writes: Patrick == Patrick Galbraith p...@patg.net writes: Patrick Monty, Patrick I saw your message in IRC - I replied in case you don't see it . I want Patrick to get this into the tree soon and am only having a small problem right now: Patrick [08:06] CaptTofu montywi: I am striving to Patrick [08:08] CaptTofu montywi: I just have one issue to solve - if the Patrick engine is build as a plugin, how I can get the test to run. right now, Patrick when it runs, it doesn't find the engine loaded, so it skips the test. I Patrick tried to add a 'load plugin' to the test, but it can find the shared Patrick library because it expects it to be in (errno: 2 Patrick dlopen(/Users/patg/code_devel/federated/lib/mysql/plugin/ha_federatedx.so, Patrick 2): image not found) We should probably try to fix that for the test suite. Kristian, do you have any ideas for this ? The existing test mysql-test/t/plugin.test does something similar to this. It uses an option file (plugin-master.opt) to set the plugin directory where mysqld will search for the .so file. I was able to load a plugin with a test case using INSTALL PLUGIN as follows: In file mysql-test/t/kn-master.opt: --plugin-dir=$MYSQL_TEST_DIR/../storage/example/.libs In file mysql-test/t/kn.test: INSTALL PLUGIN example SONAME 'ha_example.so'; Something similar should work for ha_federatedx. The tricky thing is to get this to work without failing on Windows (where the plugin is instead called .dll), and in the case where federatedx is not built (eg. ./configure option, the plugin will not be found). For plugin.test, this is solved with some special code in mysql-test-run.pl, search for EXAMPLE_PLUGIN. It would be easy to add something similar for federatedx, of course, if not exactly elegant. I can also think of other possible ways to handle this, let me know if you need it. Though the Windows case is a bit difficult at present as we have neither development people nor machines working with Windows at the moment. Patrick So, I'm wondering if to test properly, one needs to compile the engine Patrick into the server versus as a plugin? Yes, that is what you need to do (as far as I know). The above trick with setting the load path in an .opt file should work, though compiling into the server should work as well, of course. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Buildbot and compiler warnings
I have now implemented and installed in our Buildbot enhanced facilities for dealing with compiler warnings. We already have a file support-files/compiler_warnings.supp, which I think is used by PushBuild @ MySQL. The new facilities in our Buildbot uses the same file to suppress certain warnings that for some reason cannot be removed or are not desirable to remove. See for example: https://askmonty.org/buildbot/waterfall?branch=5.1 https://askmonty.org/buildbot/builders/hardy-amd64-valgrind/builds/113/steps/compile/logs/warnings So there are still a few warnings that need to be eliminated, patches welcome :-) Note that old builds from earlier than today still have the old log files, without these new warning facilities. Would be great to get us to compile without any warnings. The Drizzle people already compile with -pedantic -Werror, so we are trailing behind there! - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Documentation for new features in MariaDB
Henrik Ingo henrik.i...@avoinelama.fi writes: Now that I think about it, maybe this part of the documentation effort could for the time being be done as a diff against the MySQL manual. (Which is DocBook?) Have you checked the implications of the copyright/license issues for this idea? - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MWL#39 improving mysqlbinlog output and doing rename
Michael Widenius mo...@askmonty.org writes:
Note that it would also be very nice to have in the binlog the exact
original statement:
Kristian Yes. There was actually a customer request for this.
Kristian I think for this we would actually need a new binlog event type
Kristian (Comment_log_event?). Unless we want to log an empty statement
Query_log_event
Kristian containing only a comment (a bit of a hack).
I don't think it would be hard to add a tag to the row-binlog-event to
add the original statement in such a way that it would be backward
compatible. Someone should dig into the protocol spec to see if that
would be possible.
A Statement is logged in RBR as one or more Table_map_log_events, followed by
one or more {Write,Update,Delete}_rows_log_event. So candidates would be the
first (or last) map event, or the first row event. But the event format really
is not very extensible (I checked the code), so not trivial to make backwards
compatible.
Anyway, it should be possible, new event or squeeze into existing, whatever
works best.
Kristian BINLOG
Kristian WITH TIMESTAMP xxx SERVER_ID 1 MASTER_POS 415 FLAGS 0x0
Kristian TABLE db1.table1 AS 1 COLUMNS (INT NOT NULL, BLOB, VARCHAR(100))
FLAGS 0x0
Kristian TABLE db2.table2 AS 2 COLUMNS (CHAR(10)) FLAGS 0x0
Kristian WRITE_ROW INTO db1.table1(1,3) VALUES (42, 'foobar'), (10, NULL)
FLAGS 0x2
Kristian UPDATE_ROW INTO db2.table2 (1) (1) VALUES FROM ('beforeval') TO
('toval'),
Kristian FROM ('a') TO ('b') FLAGS 0x0
Kristian DELETE_ROW INTO db2.table2 (1) VALUES ('row_to_delete') FLAGS 0x0;
Kristian This is basically a dump of what is stored in the events, and would
be an
Kristian alternative to BINLOG 'gwWEShMBAA...'.
The above would be a much better option than using the current syntax.
After some thinking, my biggest problem with the above is that we
would have to keep the syntax up to date and extend it for every new
addition Sun makes to the binary log. Over time that may become a big
task in itself.
Yes, my main concern too.
Though I don't think there will be much addition to the format, as this would
in any case break forwards/backwards compatibility in replication. But still a
valid concern.
The problem with AWK is that it doesn't work in the general case; For
the general case to work, they would need to parse the statements into
token and ensure that they only modify things like the database
reference.
Yes, using awk (or whatever) is quite fragile (though still useful in many
cases).
For databases mysqlbinlog can do better, and for tables in RBR, as the names
are directly available in the binlog format.
For tables in SBR, or type of statement (ALTER/ANALYZE/etc.), mysqlbinlog can
do slightly better since it knows where the statement begins, but it still has
to rely on some kind of parsing.
So conclusion: it is preferable to have 100% reliable database/table/statement
filtering than having to rely on fragile awk-like post-processing.
Thanks for the input!
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MWL#39 improving mysqlbinlog output and doing rename
I read throught the worklogs, did some research, and wrote up a number of comments. I am not sure about the best way to proceed, but this is my suggestion. I have written up in this email all my comments in detail. After any discussion, I suggest I update the worklogs as per the conclusions (though if Sergey wants to do that I am happy with that as well). As you will see, this results in a huge email :-( To help this problem, I will write a separate email, laying out the possible options to be chosen between without technical detail, along with guestimates of time needed to implement. --- General comments: 1. RBR vs. SBR. A fundamental decision in several of the worklogs is whether to do something for RBR only, or something that works for both SBR and RBR. Clearly it is preferable to have the features work the same for both RBR and SBR, but it also rather more difficult to implement. There are already a lot of subtle differences between SBR and RBR in the existing similar options for master and slave, motivated by this difficulty I assume. And the problem is even harder to solve in mysqlbinlog, as we lack information available inside the server (table definitions, parsed SQL statement). There is a need to choose between ease of implementation and completeness of feature. This makes it particular important to be consistent in the choices between the different worklogs. We don't want to make the choice one way in one worklog and the other way in another, as this would cause even more confusion for the user. 2. Quoting semantics. Several of the worklogs require the parsing of table names, eg. from command line options or comments. This is a non-trivial problem, as backtick quotes `...` allow more or less any character in database or table names. There may also be issues of charater sets. For example, this is accepted: mysql create table `'db.table'` (a int); In the RBR events, the names are stored as bytes prefixed with length, so there is no issue of parsing. I assume the character set implied is utf8, though I need to check. In the command line options like --binlog-rewrite-db=db1-db2 and --binlog-do-table=db.t1, we need to decide what to do. I think it is reasonable to not support everything, as long as the semantics of what the option does is clear. For example, assume table names are given in utf8 (irrespectively of locate), and give an error if special characters like . or - is given in the names. Alternatively, we could try to support the full set of valid database and table names, and character sets. Then mysqlbinlog would consult the locale and convert to utf8. And we would need to implement a parser for quoted names, so one can say --binlog-do-table=`'my.strange.db'`.`my-wierd-table`, or --binlog-rewrite-db=`a-b`-`A-B'. One disadvantage is that this (probably?) differs from existing --replicate-do-table etc. options. For MWL#40 option 2.3, there is the suggestion to list tables in a comment: /* !mysqlbinlog: updates t1,db3.t2 */ UPDATE t1 LEFT JOIN ... In this case the problem is a bit more serious, as strange table names that are not handled correctly could make the binlog totally corrupt (eg. comment end */ in the names). I am really not comfortable with deliberately implementing such a bug, even if it is unlikely to cause any issues in normal cases. I am actually not sure about the character set implied for an SBR event. I think maybe it is given by values of system variables, which would make the problem somewhat harder to solve fully. Or maybe statements are converted to utf8 before being logged. I need to check. One option is to give an error if the option to add the comments is enabled and any table names are strange. Not a 100% clean solution, but simple and maybe acceptable. Alternatively we could implement full quoting in the master, and full parsing of quoted names in mysqlbinlog. Though I still need to do more research to know how to handle character set. 3. Option names. I think the mysqlbinlog command-line option names should not begin with --replicate, as they do not really affect replication, though they are of course related to the slave --replicate-* options. Maybe just drop the --replicate prefix, eg. --do-table, --do-table-wild, --rewrite-db, etc. This is consistent with the existing --database option of mysqlbinlog, which has no --replicate prefix. 4. Adding too many options. One thought reading through these worklogs is that we need to be careful that we do not start adding seperate options for every conceivable filtering of the mysqlbinlog output. If this would happen, we should instead add a general way to do this. Certainly fintering options on table and database name is fine. Filtering of statement types (ALTER/ANALYZE/...), MWL#41, is starting to smell a little bit like too much complexity, though maybe it is ok. Something to keep in mind. 5. Security issues
Re: [Maria-developers] Buildbot confused by non-monotonicity of revision numbers in the tree
Kristian Nielsen kniel...@knielsen-hq.org writes: Kristian Nielsen kniel...@knielsen-hq.org writes: Also, I think I will write a feature request for Launchpad to include the revision ids in the email notifications, so at least the information can be made available to the PHP pages. https://bugs.launchpad.net/launchpad-code/+bug/419057 Unfortunately, this is the comment I got on the bug: From: Aaron Bentley aa...@canonical.com One of the design goals of bzr is that revision-ids should not appear in the UI. If you are really concerned, you can set the append_revisions_only flag in the relevant branches. :-(. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Simple compiler warning fixes for yassl-1.9.6
The attached patch contains a few simple fixes for compiler warnings that I
applied to our copy of YaSSL in the MariaDB source tree
(http://askmonty.org/wiki/index.php/MariaDB).
I am sending you these in case you want to include them in upstream YaSSL.
I did not see instructions for submitting patches at http://www.yassl.com/, so
please let me know if there is some other email address or procedure I should
follow.
Signed-off-by: Kristian Nielsen kniel...@knielsen-hq.org
diff -u --recursive yassl-1.9.6.orig/include/yassl_int.hpp yassl-1.9.6.new/include/yassl_int.hpp
--- yassl-1.9.6.orig/include/yassl_int.hpp 2008-08-13 20:42:55.0 +0200
+++ yassl-1.9.6.new/include/yassl_int.hpp 2009-08-27 12:14:17.0 +0200
@@ -449,7 +449,7 @@
const CiphersGetCiphers()const;
const DH_Parms GetDH_Parms() const;
const Stats GetStats() const;
-const VerifyCallback getVerifyCallback() const;
+VerifyCallback getVerifyCallback() const;
pem_password_cb GetPasswordCb() const;
void* GetUserData() const;
boolGetSessionCacheOff() const;
diff -u --recursive yassl-1.9.6.orig/src/handshake.cpp yassl-1.9.6.new/src/handshake.cpp
--- yassl-1.9.6.orig/src/handshake.cpp 2008-11-04 00:58:32.0 +0100
+++ yassl-1.9.6.new/src/handshake.cpp 2009-08-27 12:15:09.0 +0200
@@ -798,7 +798,7 @@
{
if (ssl.GetError()) return;
-if (DoProcessReply(ssl))
+if (DoProcessReply(ssl)) {
// didn't complete process
if (!ssl.getSocket().IsNonBlocking()) {
// keep trying now, blocking ok
@@ -808,6 +808,7 @@
else
// user will have try again later, non blocking
ssl.SetError(YasslError(SSL_ERROR_WANT_READ));
+}
}
@@ -882,11 +883,12 @@
// send change cipher
void sendChangeCipher(SSL ssl, BufferOutput buffer)
{
-if (ssl.getSecurity().get_parms().entity_ == server_end)
+if (ssl.getSecurity().get_parms().entity_ == server_end) {
if (ssl.getSecurity().get_resuming())
ssl.verifyState(clientKeyExchangeComplete);
else
ssl.verifyState(clientFinishedComplete);
+}
if (ssl.GetError()) return;
ChangeCipherSpec ccs;
diff -u --recursive yassl-1.9.6.orig/src/yassl_imp.cpp yassl-1.9.6.new/src/yassl_imp.cpp
--- yassl-1.9.6.orig/src/yassl_imp.cpp 2008-11-04 02:44:02.0 +0100
+++ yassl-1.9.6.new/src/yassl_imp.cpp 2009-08-27 12:16:28.0 +0200
@@ -1311,7 +1311,7 @@
else
ssl.useSecurity().use_connection().sessionID_Set_ = false;
-if (ssl.getSecurity().get_resuming())
+if (ssl.getSecurity().get_resuming()) {
if (memcmp(session_id_, ssl.getSecurity().get_resume().GetID(),
ID_LEN) == 0) {
ssl.set_masterSecret(ssl.getSecurity().get_resume().GetSecret());
@@ -1326,6 +1326,7 @@
ssl.useSecurity().set_resuming(false);
ssl.useLog().Trace(server denied resumption);
}
+}
if (ssl.CompressionOn() !compression_method_)
ssl.UnSetCompression(); // server isn't supporting yaSSL zlib request
diff -u --recursive yassl-1.9.6.orig/src/yassl_int.cpp yassl-1.9.6.new/src/yassl_int.cpp
--- yassl-1.9.6.orig/src/yassl_int.cpp 2008-11-04 02:13:38.0 +0100
+++ yassl-1.9.6.new/src/yassl_int.cpp 2009-08-27 12:16:55.0 +0200
@@ -1840,7 +1840,7 @@
}
-const VerifyCallback SSL_CTX::getVerifyCallback() const
+VerifyCallback SSL_CTX::getVerifyCallback() const
{
return verifyCallback_;
}
diff -u --recursive yassl-1.9.6.orig/taocrypt/include/modes.hpp yassl-1.9.6.new/taocrypt/include/modes.hpp
--- yassl-1.9.6.orig/taocrypt/include/modes.hpp 2007-03-15 03:15:12.0 +0100
+++ yassl-1.9.6.new/taocrypt/include/modes.hpp 2009-08-27 12:17:46.0 +0200
@@ -103,11 +103,12 @@
{
if (mode_ == ECB)
ECB_Process(out, in, sz);
-else if (mode_ == CBC)
+else if (mode_ == CBC) {
if (dir_ == ENCRYPTION)
CBC_Encrypt(out, in, sz);
else
CBC_Decrypt(out, in, sz);
+}
}
diff -u --recursive yassl-1.9.6.orig/taocrypt/src/asn.cpp yassl-1.9.6.new/taocrypt/src/asn.cpp
--- yassl-1.9.6.orig/taocrypt/src/asn.cpp 2008-05-23 03:29:25.0 +0200
+++ yassl-1.9.6.new/taocrypt/src/asn.cpp 2009-08-27 12:18:37.0 +0200
@@ -786,11 +786,12 @@
memcpy(date, source_.get_current(), length);
source_.advance(length);
-if (!ValidateDate(date, b, dt) verify_)
+if (!ValidateDate(date, b, dt) verify_) {
if (dt == BEFORE)
source_.SetError(BEFORE_DATE_E);
else
source_.SetError(AFTER_DATE_E);
+}
// save for later use
if (dt == BEFORE) {
@@ -1067,7 +1068,7 @@
return 0;
}
word32 rLen = GetLength(source);
-if (rLen != 20)
+if (rLen != 20
Re: [Maria-developers] Rev 2747: Gcov support improvements in file:///home/psergey/dev/maria-5.1-table-elim-r11-gcov/
Sergey Petrunya pser...@askmonty.org writes:
At file:///home/psergey/dev/maria-5.1-table-elim-r11-gcov/
revno: 2747
revision-id: pser...@askmonty.org-20090825150255-46i5gvl2ctd0jcm2
parent: pser...@askmonty.org-20090825145915-rxwmfczgqe69r5ju
committer: Sergey Petrunya pser...@askmonty.org
branch nick: maria-5.1-table-elim-r11-gcov
timestamp: Tue 2009-08-25 18:02:55 +0300
message:
Gcov support improvements
- add process-gcov-annotations.pl script that processes .gcov files
according to purecov annotations in source code
- add --gcov-src-dir=subdir option to mysql-test-run so that one can
do gcov processing only for source files in a certain directory.
Nice additions!
=== modified file 'mysql-test/lib/mtr_gcov.pl'
--- a/mysql-test/lib/mtr_gcov.pl 2009-04-25 09:04:38 +
+++ b/mysql-test/lib/mtr_gcov.pl 2009-08-25 15:02:55 +
@@ -62,6 +64,7 @@
$dir_reported= 1;
}
system($gcov $f 2$start_dir/$gcov_err $start_dir/$gcov_msg);
+ system(perl $basedir/mysql-test/lib/process-purecov-annotations.pl
$f.gcov);
Better do something like this:
system(perl, $basedir/mysql-test/lib/process-purecov-annotations.pl,
$f.gcov);
as it is robust to spaces and other shell metachars in the data.
=== added file 'mysql-test/lib/process-purecov-annotations.pl'
--- a/mysql-test/lib/process-purecov-annotations.pl 1970-01-01 00:00:00
+
+++ b/mysql-test/lib/process-purecov-annotations.pl 2009-08-25 15:02:55
+
+# Besides purecov annotations, also remove uncovered code mark from cases
+# like the following:
+#
+# -: 211:*/
+# -: 212:class Field_value : public Value_dep
+# #: 213:{
+# -: 214:public:
+#
+# I have no idea why would gcov think there is uncovered code there
Maybe generated default constructor, destructor, or the like that was not run?
+#
+my @arr= split(/:/, $line);
+if ($skipping || $line =~ /purecov: *(inspected|deadcode)/ ||
+$arr[2] =~ m/^{ */)
Note that m/^{ */ matches the same lines as m/^{/. Maybe you intended to use
m/^{ *$/ to require the line to be empty except for a starting brace? Or else
just use m/^{/.
+{
+ # Change '' to '-'.
+ $arr[0] =~ s/#/-/g;
+ $line= join(:, @arr);
+}
+print OUT $line;
+ }
+ close(IN);
+ close(OUT);
+ system(cat $out_file_name $in_file_name);
+ system(rm $out_file_name);
system(mv, -f, $out_file_name, $in_file_name);
(or cp / rm with multi-argument system()).
=== modified file 'mysql-test/mysql-test-run.pl'
--- a/mysql-test/mysql-test-run.pl2009-06-22 08:06:35 +
+++ b/mysql-test/mysql-test-run.pl2009-08-25 15:02:55 +
@@ -169,6 +169,7 @@
our $opt_mem= $ENV{'MTR_MEM'};
our $opt_gcov;
+our $opt_gcov_src_dir;
Don't you need to initialise to empty string '' to avoid a warning with
undefined value? (Or maybe getopt handles it?).
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Merge] lp:~paul-mccullagh/maria/maria-pbxt-rc2 into lp:maria
Paul McCullagh paul.mccull...@primebase.org writes: mysqltest: At line 3: query 'alter table t1 rename mysqltest.t1' failed: 1025: Error on rename of './test/t1' to './mysqltest/ t1' (errno: 16) Occurs because the PBMS code is compiled in. This can be disabled by commenting out: #define PBMS_ENABLED in xt_defs.h [xt_config.h actually] This is, in fact, a bug in PBMS. I have already reported the bug here: https://bugs.launchpad.net/pbms/+bug/416969 So, if the PBMS_ENABLED code is disable (which should probably be the default at the moment), then that test should run through. Ok, thanks, that solved 3 of the 4 remaining failures. And the last one is just a missing result file update for test pbxt.ps_1general. You have this diff in the last commit for ha_pbxt.cc: - stats.data_file_length = ot-ot_table-tab_rec_eof_id; + stats.data_file_length = xt_rec_id_to_rec_offset(ot-ot_table, ot-ot_table-tab_rec_eof_id); So the data file length output of show table status was fixed from units of records to units of bytes. I just updated the result file accordingly, from 1 to 1024. The other problems seem to have to do with case-sensitivity. I will see if I can repeat those errors on one of my machines. Yes, they are case sensitivity issues (except udf maybe). As I said, they all pass with the patch I gave, which just adds missing *-master.opt files that are in the main test suite, but where not copied into the pbxt suite along with the *.test files. So I will merge this into MariaDB with attached patch to disable PBMS and fix test failures. I really want to also enable the PBXT test suite in our Buildbot. Unfortunately I am really pressed for time do do this now. For one, I see a number of Valgrind errors when running the suite that I need to investigate. But one of these days, Thanks, - Kristian. -- https://code.launchpad.net/~paul-mccullagh/maria/maria-pbxt-rc2/+merge/10303 Your team Maria developers is subscribed to branch lp:maria.=== modified file 'mysql-test/suite/pbxt/r/lowercase_view.result' --- mysql-test/suite/pbxt/r/lowercase_view.result 2009-04-02 20:36:52 + +++ mysql-test/suite/pbxt/r/lowercase_view.result 2009-08-31 11:07:44 + @@ -119,7 +119,7 @@ create table t1Aa (col1 int); create view v1Aa as select col1 from t1Aa as AaA; show create view v1AA; View Create View character_set_client collation_connection -v1aa CREATE ALGORITHM=UNDEFINED definer=`ro...@`localhost` SQL SECURITY DEFINER VIEW `v1aa` AS select `AaA`.`col1` AS `col1` from `t1aa` `AaA` latin1 latin1_swedish_ci +v1aa CREATE ALGORITHM=UNDEFINED definer=`ro...@`localhost` SQL SECURITY DEFINER VIEW `v1aa` AS select `aaa`.`col1` AS `col1` from `t1aa` `aaa` latin1 latin1_swedish_ci drop view v1AA; select Aaa.col1 from t1Aa as AaA; col1 @@ -128,7 +128,7 @@ drop view v1AA; create view v1Aa as select AaA.col1 from t1Aa as AaA; show create view v1AA; View Create View character_set_client collation_connection -v1aa CREATE ALGORITHM=UNDEFINED definer=`ro...@`localhost` SQL SECURITY DEFINER VIEW `v1aa` AS select `AaA`.`col1` AS `col1` from `t1aa` `AaA` latin1 latin1_swedish_ci +v1aa CREATE ALGORITHM=UNDEFINED definer=`ro...@`localhost` SQL SECURITY DEFINER VIEW `v1aa` AS select `aaa`.`col1` AS `col1` from `t1aa` `aaa` latin1 latin1_swedish_ci drop view v1AA; drop table t1Aa; CREATE TABLE t1 (a int, b int); @@ -142,7 +142,7 @@ CREATE OR REPLACE VIEW v1 AS select X.a from t1 AS X group by X.b having (X.a = 1); SHOW CREATE VIEW v1; View Create View character_set_client collation_connection -v1 CREATE ALGORITHM=UNDEFINED definer=`ro...@`localhost` SQL SECURITY DEFINER VIEW `v1` AS select `X`.`a` AS `a` from `t1` `X` group by `X`.`b` having (`X`.`a` = 1) latin1 latin1_swedish_ci +v1 CREATE ALGORITHM=UNDEFINED definer=`ro...@`localhost` SQL SECURITY DEFINER VIEW `v1` AS select `x`.`a` AS `a` from `t1` `x` group by `x`.`b` having (`x`.`a` = 1) latin1 latin1_swedish_ci SELECT * FROM v1; a DROP VIEW v1; === modified file 'mysql-test/suite/pbxt/r/ps_1general.result' --- mysql-test/suite/pbxt/r/ps_1general.result 2009-08-17 15:57:58 + +++ mysql-test/suite/pbxt/r/ps_1general.result 2009-08-31 11:07:44 + @@ -293,7 +293,7 @@ t2 1 t2_idx 1 b A 0 NULL NULL YES BTREE prepare stmt4 from ' show table status from test like ''t2%'' '; execute stmt4; Name Engine Version Row_format Rows Avg_row_length Data_length Max_data_length Index_length Data_free Auto_increment Create_time Update_time Check_time Collation Checksum Create_options Comment -t2 PBXT 10 Fixed 0 29 1 # 4096 0 NULL # # # latin1_swedish_ci NULL +t2 PBXT 10 Fixed 0 29 1024 # 4096 0 NULL # # # latin1_swedish_ci NULL prepare stmt4 from ' show table status from test like ''t9%'' '; execute stmt4; Name Engine Version Row_format Rows Avg_row_length Data_length Max_data_length Index_length Data_free Auto_increment Create_time Update_time Check_time Collation Checksum Create_options Comment
Re: [Maria-developers] MariaDB versioning
Peter Laursen peter_laur...@webyog.com writes: I have a concern that I will ask you all to consider while there is time. I think I understand that after MariaDB 5.1 a 5.2 release is planned. I think it should not be versioned like that. Problem is that there is a MySQL 5.2 tree too (it is basically an early 6.0) and it is still available for download from FTP-mirrors like ftp://mirrors.dotsrc.org/mysql/Downloads/ . . For generic and GUI clients (ie. not designed for specific server versions and where SQL is generated and not written by user) it is important that the version string can be used to identify what SQL statements are supported by server. The first thing such clients (like our own SQLyog) does after connection is to SELECT VERSION() .. and only after that we know if there is support for EVENTS, if IF EXISTS is supported for DROP TRIGGER sysntax and so on. If there are two different 5.2 trees (MariaDB based on MySQL 5.1 and MySQL 5.2) it gets more difficult to handle. Thanks for taking up this issue. I agree of course with your concerns about versioning. The problem is that numbers are linear, but source code branches/forks form a tree. So if we want to release a separate branch of MariaDB which has more features than the MariaDB-5.1 branch, but less than MySQL 5.2/5.4/6.0. How will we name that version? We were thinking to use 5.2 as that version was never properly released. But what would be a better option? Of course, MySQL already broke this somewhat, as 5.4 is based on 5.1 with some patches (AFAIK), so might concievably be missing some features that are in 5.2. And I have also understood that MySQL has now likewise abandoned the 5.4 version just like the 6.0 version. Suggestions welcome, we will need to think carefully about this and follow events to choose the correct path forward. Or failing that at least the one that is the least broken. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Merge] lp:~paul-mccullagh/maria/maria-pbxt-rc2 into lp:maria
Kristian Nielsen kniel...@knielsen-hq.org writes: So I will merge this into MariaDB with attached patch to disable PBMS and fix test failures. Ok, so I merged it. But now I have a problem with PBXT crashing sometimes during shutdown. To reproduce, run the following command in a build of lp:maria: mkdir -p /tmp/x sql/mysqld --no-defaults --basedir=$(pwd) --character-sets-dir=$(pwd)/sql/share/charsets --language=$(pwd)/sql/share/english --skip-networking --datadir=/tmp/x --skip-grant-tables --nonexistentoption This is supposed to complain about bad --nonexistentoption, and exit. Instead, in about 75% of cases it crashes during shutdown :-(. Basically, it crashes when the thread that calls xt_init_databases() is different from the thread that calls xt_stop_database_threads(), xt_exit_databases(), and db_finalize(). For some reason, this is usually, but not always, done in different threads in this scenario. Here is the stack trace: ==16085== Invalid read of size 4 ==16085==at 0x9DFB78: xt_sl_delete(XTThread*, XTSortedList*, void*) (sortedlist_xt.cc:205) ==16085==by 0xA14461: db_finalize(XTThread*, void*) (database_xt.cc:323) ==16085==by 0x9C340E: xt_heap_release(XTThread*, XTHeap*) (heap_xt.cc:110) ==16085==by 0xA133AA: xt_unuse_database(XTThread*, XTThread*) (database_xt.cc:662) ==16085==by 0xA1341C: xt_db_exit_thread(XTThread*) (database_xt.cc:682) ==16085==by 0x9F6F07: thr_exit(XTThread*) (thread_xt.cc:1051) ==16085==by 0x9F711A: xt_free_thread(XTThread*) (thread_xt.cc:1445) ==16085==by 0x9F9345: thr_main (thread_xt.cc:1028) ==16085==by 0x50463F6: start_thread (pthread_create.c:297) ==16085==by 0x6026B3C: clone (in /usr/lib/debug/libc-2.7.so) ==16085== Address 0x44 is not stack'd, malloc'd or (recently) free'd So, I do not know why the thread is sometimes the same and sometimes not in startup and shutdown. I guess it is some kind of race condition? Can you help with a suggestion on how to fix? - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Merge] lp:~paul-mccullagh/maria/maria-pbxt-rc2 into lp:maria
Kristian Nielsen kniel...@knielsen-hq.org writes: Ok, so I merged it. But now I have a problem with PBXT crashing sometimes during shutdown. Filed a bug on this on Launchpad: https://bugs.launchpad.net/maria/+bug/422550 - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB and the SCA
Kristian Nielsen kniel...@knielsen-hq.org writes: Davi Arnaut davi.arn...@sun.com writes: I've been monitoring the maria-developers list and there are some patches that we would like to gradually incorporate into our branches. For a practical example, i would like to merge into 5.1 parts of this (http://tinyurl.com/q2ulgt) patch by Kristian. Negotiations between Monty Program and Sun have started some time ago on a deal which would cover how Sun will get the rights it needs (ie. SCA) to include the MariaDB code into the MySQL code, and how Monty Program will receive compensation for giving these rights. As I understand it, these negotiations are however still in the early phase. Apparently, this is moving nowhere :-(. Davi, I'm sorry there has been no progress on this. We discussed this again in MariaDB, and would like to get things working better for now. What Monty suggested was that it would work for Sun if we submit specific patches under a BSD-new license. I realise that the http://tinyurl.com/q2ulgt patch request is now so old that it may be of no interest to you any longer. But if you have a request for this or other patches, please send them. All developers at Monty Program have the ability to submit their work to Sun at their own discretion, so we should be able to make this work on a low-overhead technician-to-technician level. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Branch ~maria-captains/maria/5.1] Rev 2726: Updated documentation files to reflect MariaDB and not the Maria storage engine or MySQL
nore...@launchpad.net writes:
Merge authors:
Michael Widenius (monty)
revno: 2726 [merge]
committer: Michael Widenius mo...@mysql.com
branch nick: maria
timestamp: Thu 2009-09-03 17:56:46 +0300
message:
Updated documentation files to reflect MariaDB and not the Maria storage
engine or MySQL
Added (rewritten) patch from Percona to get extended statistics in slow.log:
=== modified file 'sql/log.cc'
--- sql/log.cc2009-04-25 10:05:32 +
+++ sql/log.cc2009-09-03 14:05:38 +
@@ -987,6 +987,17 @@
query_length= command_name[thd-command].length;
}
+if (!query_length)
+{
+ /*
+Not a real query; Reset counts for slow query logging
+(QQ: Wonder if this is really needed)
+ */
+ thd-sent_row_count= thd-examined_row_count= 0;
+ thd-query_plan_flags= QPLAN_INIT;
+ thd-query_plan_fsort_passes= 0;
+}
This part of the patch makes me wonder. Isn't this dead code? Just above, the
code does this:
if (!query)
{
is_command= TRUE;
query= command_name[thd-command].str;
query_length= command_name[thd-command].length;
}
So the above part of the patch will only run when query!=0 query_length==0.
Can this ever happen?
If not, the code should probably be removed. If so, maybe add a comment
explaining when this happens (and change it to be in an else {} clause of the
if statement just before it).
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Rev 2726: Exclude innodb_plugin form MariaDB's max and max-no-ndb configurations and in file:///home/psergey/bzr-new/mysql-5.1-maria-contd3/
Hm, seems I forgot to attach the patch. - Kristian. === modified file 'mysql-test/r/innodb.result' --- mysql-test/r/innodb.result 2009-09-07 20:50:10 + +++ mysql-test/r/innodb.result 2009-09-10 13:00:42 + @@ -1738,7 +1738,7 @@ count(*) drop table t1; SELECT variable_value FROM information_schema.global_status WHERE LOWER(variable_name) = 'innodb_buffer_pool_pages_total'; variable_value -512 +511 SELECT variable_value FROM information_schema.global_status WHERE LOWER(variable_name) = 'innodb_page_size'; variable_value 16384 @@ -1784,7 +1784,7 @@ innodb_sync_spin_loops 20 SET @old_innodb_thread_concurrency= @@global.innodb_thread_concurrency; show variables like innodb_thread_concurrency; Variable_name Value -innodb_thread_concurrency 8 +innodb_thread_concurrency 0 set global innodb_thread_concurrency=1001; Warnings: Warning 1292 Truncated incorrect thread_concurrency value: '1001' === modified file 'mysql-test/t/bug46080-master.opt' --- mysql-test/t/bug46080-master.opt 2009-07-10 12:00:34 + +++ mysql-test/t/bug46080-master.opt 2009-09-10 13:36:22 + @@ -1 +1 @@ ---skip-grant-tables --skip-name-resolve --safemalloc-mem-limit=400 +--skip-grant-tables --skip-name-resolve --safemalloc-mem-limit=2000 === modified file 'mysql-test/t/innodb.test' --- mysql-test/t/innodb.test 2009-09-07 20:50:10 + +++ mysql-test/t/innodb.test 2009-09-10 12:44:52 + @@ -1317,6 +1317,10 @@ drop table t1; # Test for testable InnoDB status variables. This test # uses previous ones(pages_created, rows_deleted, ...). + +# InnoDB aligns the memory for the buffer pool to a page boundary. This may +# cause actual pool size to be one less than requested depending on exact +# alignment of obtained memory. --replace_result 512 511 SELECT variable_value FROM information_schema.global_status WHERE LOWER(variable_name) = 'innodb_buffer_pool_pages_total'; SELECT variable_value FROM information_schema.global_status WHERE LOWER(variable_name) = 'innodb_page_size'; Kristian Nielsen kniel...@knielsen-hq.org writes: Hi Sergey, Attached patch fixes two more failures in the merge as seen in Buildbot. The main.innodb failures are two different issues. One I already fixed in another place in XtraDB, I added a comment to explain better. The other looks like a merge error, the result file was changed in the merge but the output of the test did not change. The main.bug46080 failure is really due to a poor test case. It checks that an out-of-memory condition does not crash the server, but it does so poorly using --safemalloc-mem-limit=400. This requires all kinds of assumptions about how much memory is actually used. MariaDB uses more memory (due to the Maria storage engine I assume). I increased the value to something reasonable for Maria that should still trigger the out-of-memory condition. The better fix would be to re-write the test case to use error injection. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Diff for stuff from MySQL 5.1.38 not yet included in the merge
Hi Sergey,
Here is the diff of the commits that are not yet merged from MySQL 5.1.38
(they are missing from our merge since they were not yet pushed to Launchpad
by the MySQL build team when the merge was done by Jani and Monty).
There is a Windows build one-liner, but don't know if it will help you.
I will merge this into maria-5.1-merge as soon as you have pushed your merge
with latest lp:maria.
- Kristian.
=== modified file '.bzrignore'
--- .bzrignore 2009-02-27 11:20:53 +
+++ .bzrignore 2009-08-12 20:06:44 +
@@ -3063,3 +3063,4 @@ sql/share/slovak
sql/share/spanish
sql/share/swedish
sql/share/ukrainian
+libmysqld/examples/mysqltest.cc
=== modified file 'CMakeLists.txt'
--- CMakeLists.txt 2009-08-11 15:47:33 +
+++ CMakeLists.txt 2009-08-14 15:18:52 +
@@ -137,6 +137,7 @@ ENDIF(MSVC)
IF(WIN32)
ADD_DEFINITIONS(-D_WINDOWS -D__WIN__ -D_CRT_SECURE_NO_DEPRECATE)
+ ADD_DEFINITIONS(-D_WIN32_WINNT=0x0501)
ENDIF(WIN32)
# default to x86 platform. We'll check for X64 in a bit
=== modified file 'cmd-line-utils/readline/util.c'
--- cmd-line-utils/readline/util.c 2009-06-29 13:17:01 +
+++ cmd-line-utils/readline/util.c 2009-08-14 15:18:52 +
@@ -81,8 +81,13 @@ rl_alphabetic (c)
#if defined (HANDLE_MULTIBYTE)
int
-_rl_walphabetic (wc)
- wchar_t wc;
+/*
+ Portability issue with VisualAge C++ Professional / C for AIX Compiler,
Version 6:
+util.c, line 84.1: 1506-343 (S) Redeclaration of _rl_walphabetic differs
+from previous declaration on line 110 of rlmbutil.h.
+ So, put type in the function signature here.
+*/
+_rl_walphabetic (wchar_t wc)
{
int c;
=== modified file 'mysql-test/Makefile.am'
--- mysql-test/Makefile.am 2009-07-14 10:06:04 +
+++ mysql-test/Makefile.am 2009-08-21 11:58:33 +
@@ -17,7 +17,8 @@
## Process this file with automake to create Makefile.in
-testdir = $(prefix)/mysql-test
+testroot = $(prefix)
+testdir = $(testroot)/mysql-test
test_SCRIPTS = mtr \
mysql-test-run \
=== modified file 'mysql-test/lib/My/SafeProcess/Makefile.am'
--- mysql-test/lib/My/SafeProcess/Makefile.am 2008-03-13 16:07:11 +
+++ mysql-test/lib/My/SafeProcess/Makefile.am 2009-08-21 11:58:33 +
@@ -13,7 +13,8 @@
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-safedir = $(prefix)/mysql-test/lib/My/SafeProcess
+testroot = $(prefix)
+safedir = $(testroot)/mysql-test/lib/My/SafeProcess
#nobase_bin_PROGRAMS = ...
safe_PROGRAMS =my_safe_process
=== modified file 'scripts/make_win_bin_dist'
--- scripts/make_win_bin_dist 2009-04-14 19:53:00 +
+++ scripts/make_win_bin_dist 2009-09-01 06:40:13 +
@@ -279,6 +279,7 @@ cp include/mysql/plugin.h $DESTDIR/inclu
# --
mkdir -p $DESTDIR/lib/opt
+mkdir -p $DESTDIR/lib/plugin
cp libmysql/$TARGET/libmysql.dll \
libmysql/$TARGET/libmysql.lib \
libmysql/$TARGET/mysqlclient.lib \
@@ -286,6 +287,10 @@ cp libmysql/$TARGET/libmysql.dll \
regex/$TARGET/regex.lib \
strings/$TARGET/strings.lib \
zlib/$TARGET/zlib.lib $DESTDIR/lib/opt/
+if [ -d storage/innodb_plugin ]; then
+ cp storage/innodb_plugin/$TARGET/ha_innodb_plugin.dll \
+ $DESTDIR/lib/plugin/
+fi
if [ x$TARGET != xrelease ] ; then
cp libmysql/$TARGET/libmysql.pdb \
@@ -294,11 +299,17 @@ if [ x$TARGET != xrelease ] ; then
regex/$TARGET/regex.pdb \
strings/$TARGET/strings.pdb \
zlib/$TARGET/zlib.pdb $DESTDIR/lib/opt/
+ if [ -d storage/innodb_plugin ]; then
+cp storage/innodb_plugin/$TARGET/ha_innodb_plugin.pdb \
+ $DESTDIR/lib/plugin/
+ fi
fi
+
if [ x$PACK_DEBUG = x -a -f libmysql/debug/libmysql.lib -o \
x$PACK_DEBUG = xyes ] ; then
mkdir -p $DESTDIR/lib/debug
+ mkdir -p $DESTDIR/lib/plugin/debug
cp libmysql/debug/libmysql.dll \
libmysql/debug/libmysql.lib \
libmysql/debug/libmysql.pdb \
@@ -312,6 +323,12 @@ if [ x$PACK_DEBUG = x -a -f libmysq
strings/debug/strings.pdb \
zlib/debug/zlib.lib \
zlib/debug/zlib.pdb $DESTDIR/lib/debug/
+ if [ -d storage/innodb_plugin ]; then
+cp storage/innodb_plugin/debug/ha_innodb_plugin.dll \
+ storage/innodb_plugin/debug/ha_innodb_plugin.lib \
+ storage/innodb_plugin/debug/ha_innodb_plugin.pdb \
+ $DESTDIR/lib/plugin/debug/
+ fi
fi
# --
=== modified file 'storage/innodb_plugin/handler/i_s.cc'
--- storage/innodb_plugin/handler/i_s.cc2009-06-10 08:59:49 +
+++ storage/innodb_plugin/handler/i_s.cc2009-08-14 15:18:52 +
@@ -69,14 +69,16 @@ do {
\
#define STRUCT_FLD(name, value)value
#endif
-static const ST_FIELD_INFO END_OF_ST_FIELD_INFO =
-
Re: [Maria-developers] Rev 2746: Fix mysql-test-run on windows: in file:///home/psergey/bzr-new/mysql-5.1-maria-contd4/
Sergey Petrunya pser...@askmonty.org writes:
At file:///home/psergey/bzr-new/mysql-5.1-maria-contd4/
revno: 2746
revision-id: pser...@askmonty.org-20090917001350-pyxja2suxylxhez1
parent: pser...@askmonty.org-20090916190503-kgckwua1roxhonsy
committer: Sergey Petrunya pser...@askmonty.org
branch nick: mysql-5.1-maria-contd4
timestamp: Thu 2009-09-17 04:13:50 +0400
message:
Fix mysql-test-run on windows:
- Make it not to add '--console' when '--log-error' option is present
=== modified file 'mysql-test/mysql-test-run.pl'
--- a/mysql-test/mysql-test-run.pl2009-09-15 10:46:35 +
+++ b/mysql-test/mysql-test-run.pl2009-09-17 00:13:50 +
@@ -4433,7 +4433,9 @@
if (IS_WINDOWS)
{
# Trick the server to send output to stderr, with --console
-mtr_add_arg($args, --console);
+if (!(join(' ', @$args) =~ /--log-error/)) {
+ mtr_add_arg($args, --console);
+}
There is no need to create a joined string to grep here. It can be simplified
like this:
if (!(grep(/^--log-error/, @$args))) { ... }
or, if you really want to catch _all_ occurences of --log-error (including
--tmpdir=/var/--log-error/tmp), then this:
if (!(grep(/--log-error/, @$args))) { ... }
Hope this helps,
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (igor:2744)
Igor Babaev i...@askmonty.org writes: #At lp:maria based on revid:i...@askmonty.org-20090916174301-lzzh1r0khn3dxwvp 2744 Igor Babaev 2009-09-16 Fixed a failure of the merge_innodb test on windows. modified: storage/myisammrg/ha_myisammrg.cc === modified file 'storage/myisammrg/ha_myisammrg.cc' --- a/storage/myisammrg/ha_myisammrg.cc 2009-09-07 20:50:10 + +++ b/storage/myisammrg/ha_myisammrg.cc 2009-09-17 03:36:21 + @@ -309,7 +309,7 @@ static MI_INFO *myisammrg_attach_childre TABLE *parent; TABLE *child; TABLE_LIST*child_l; - MI_INFO *myisam; + MI_INFO *myisam= NULL; DBUG_ENTER(myisammrg_attach_children_callback); my_errno= 0; Are you sure this fixes the failure? The reason I ask is that this change does not appear to be able to affect the result of the code in any way... The only code path where myisam is referenced without being assigned is when the table is not MYISAM (child-file-ht-db_type != DB_TYPE_MYISAM), and in this case the only reference is in a DBUG_PRINT(). So this could maybe fix a Valgrind warning, but how could it have any effect on a failure on Windows? The patch looks ok as it is, as it prevents the debug printout of an undefined value. I am just curious how this could fix a failure, maybe it is just hiding the real bug? - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Adding tests to buildbot
Hakan Kuecuekyilmaz ha...@askmonty.org writes: Kristian, I have now a rough idea on how to run our make distcheck test. What I need is a howto about adding tests to buildbot. In Pushbuild times, BUILD/compile-dist make dist was run prior to all other tests. The machines connected to Pushbuild would pull the .tar.gz archive to start their tests. I think, we don't really need that, but we need to test make distcheck is working. Yes, Pushbuild had one job than ran and produced a source .tar.gz from `make dist`. And this was uploaded to most other build slaves as the basis for their builds. The good point about this approach is that it tests the actual sources that we are releasing, and forgettting to add some file to the list of what goes into the source tarball is a very common mistake. It also allows to test that the source can be built without having autotools, bison, etc. installed. The problem with out buildbot setup is that our slaves are too poorly connected network wise. I fear constantly up- and downloading source tarballs would overload internet connections. It could work well for machines on the same LAN as the Buildbot master though. However, we could do something simpler, something like this: BUILD/autorun.sh make -j4 dist find . -maxdepth 1 \( -name 'mysql-*.tar.gz -prune -o -print0) | xargs -0 rm -Rf gzip -dc mysql-*.tar.gz | tar xf - (cd mysql-* ./configure options make -j4) (cd mysql-*/mysql-test perl mysql-test-run.pl options) This does not catch if the build process starts depending on autotools or bison, but otherwise should work ok I think. A seperate test would be to just run `make distcheck` and check that it does not fail. This is a somewhat different test, it does not test that the resulting binary works, but it does do some extra checks (like that `make clean` works correctly). So either or both of these would be good to have. I believe Buildbot also has support for one build producing the source tarball with `make dist`, and once this is done triggering other builds to run from this. So if you want to do this it should be possible, but as you say we probably don't really need that at this point. As to a howto: - Find build slaves to run this on. - All of this can be configured just by setting up builders in the Buildbot master config file and adding appropriate buildsteps. - https://internal.askmonty.org/internal/index.php/BuildbotSetup has documentation on the setup and configuration of our Buildbot master. - /etc/buildbot/maria-master.cfg on hasky is the master config file, you can study it to see how the existing setup works. - http://djmitche.github.com/buildbot/docs/0.7.11/ is the Buildbot manual with detailed description of how the config file works. Hopefully that should get you started; feel free to ask any specific questions that may pop up. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] negative TIME in SHOW FULL PROCESSLIST and information_schema.processlist
Hi, While merging the Percona microsec_process patch (the 5.1 port of the patch is called acc-pslist), I encountered a problem related to Bug#22047: http://bugs.mysql.com/bug.php?id=22047 The issue is with the exact behaviour of the TIME column of SHOW FULL PROCESSLIST and information_schema.processlist. The documentation says (http://dev.mysql.com/doc/refman/5.1/en/show-processlist.html): Time The time in seconds that the thread has been in its current state. However, the TIME column is actually computed as current local time - @@TIMESTAMP This means that the value will differ from the documented value for threads that modify @@TIMESTAMP. In particular, it will differ for the replication thread. There is a replication FAQ, which says this: http://dev.mysql.com/doc/refman/5.1/en/replication-faq.html 16.3.4.3: How do I know how late a slave is compared to the master? You can read the Seconds_Behind_Master column in SHOW SLAVE STATUS. See Section 16.4.1,“Replication Implementation Details”. In the Time column in the output of SHOW PROCESSLIST, the number of seconds displayed for the slave SQL thread is the number of seconds between the timestamp of the last replicated event and the real time of the slave machine. You can use this to determine the date of the last replicated event. However, this does not take into account the possibility of time skew between master and slave. The actual value displayed in SHOW PROCESSLIST is current time - time of original event + time skew To me, this is just too complex to be really useful. On the other hand, Seconds_Behind_Master _does_ take into account the time skew, so it seems a much more useful metric to use to me. Frankly, to me this last part of the documentation sounds to me like trying to spin a bug as a feature. Now, the microsec_process patch adds a TIME_MS column, which works like TIME is documented, except with microsecond precision. This leaves three options to choose between: 1. Let TIME_MS also depend on @@TIMESTAMP. This is particularly ugly, as TIMESTAMP has seconds granularity, so rounding effects will be interesting. I really don't like this idea. 2. Let TIME_MS be independent of @@TIMESTAMP; it will just be the time since last state change, with microseconds resolution. But keep currently implemented semantics of TIME. This means that TIME and TIME_MS will be unrelated for threads that change @@TIMESTAMP (like the slave thread). This will be confusing. 3. Change implementation of TIME so that both TIME and TIME_MS are independent of @@TIMESTAMP. Of these, I tend to prefer option 3. Reason is that the semantics is much cleaner and simple to understand. The functionality to see how much slave is behind is in any case better obtained using Seconds_Behind_Master. However, it does involve a change in behaviour, so I want to ask opinions if anyone thinks the change in behaviour would cause too much breakage? If so, I prefer to implement option 2. If not, I will go ahead with option 3. Thanks, - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Updated (by Guest): Add a mysqlbinlog option to change the used database (36)
Hi Alexi,
Thanks for writing up the low-level design. I read it through, and have a
couple of comments:
1.3. In mysqlbinlog.cc:
- Add { rewrite-db, OPT_REWRITE_DB, ...} record to my_long_options:
- Add Rpl_filter object to mysqlbinlog.cc
Rpl_filter* binlog_filter;
Sharing code with similar replication options inside mysqld is a noble
goal. However, in this case I think it is a case of the cure is worse than
the disease.
The Rpl_filter class has _so_ much mysqld server internals that we do not want
to mix into a client application. That is also why you need to do all these
modifications in sql_list, rpl_filter, etc.
So I think it is wrong to use the Rpl_filter class in mysqlbinlog.
To share code between the two, I think the better method is to move out the
needed functionality (add_db_rewrite() and get_rewrite_db()) in a separate
class, and have both the Rpl_filter class and mysqlbinlog use that.
Alternatively, if the shared functionality is really small (as it appears it
might be), just duplicating the functionality may be better.
2. Supporting rewrite-db for RBR events
---
In binlog, each row operation event is preceded by Table map event(s) which
maps
table id(s) to database and table names. So, it's enough to support rewriting
database name in a Table map.
2.1. Add rewrite_db() member to Table_map_log_event:
int Table_map_log_event::rewrite_db(
const char* new_db,
size_t new_db_len,
const Format_description_log_event* desc)
{
/* 1. In temp_buf member (possibly reallocating it) rewrite
event length, db length, and db parts
2. Change m_dblen and m_dbnam members
You need to be careful here to avoid a memory leak. The n_dbnam memory is part
of a my_multi_malloc(), so it will not be freed in destructor (and we must not
explicitly free the old pointer).
The way the existing code works is really not all that nice for what we are
trying to do here...
It would be cleaner perhaps to have a constructor or member that builds a new
event object, but I am not sure that will work well without major rewrites
that should not be part of this worklog. So what you suggest may work, just a
warning about handling the my_multi_malloc() issue properly.
Note. write_event_header_and_base64() does not print use-statement. It
produces BINLOG statement using ev-temp_buf content (i.e. the binary
log representation of the event). We don't rewrite temp_buf here with
db_to name (as we do it for Table map event) - this implies the
limitation 3 mentioned above.
Question: Is supporting of rewite_db + --base64-output really needed
currently?
Probably it is not needed. But we should throw an error if --rewrite_db and
--base64-output=always are attempted used together.
4. Current status
-
The outlined design (implemented for mysql-5.1.37) is tested for
simple test-cases.
TODO. 1. Check list of events which can emit use-statement.
2. Supporting of rewite_db + --base64-output ?
Apart from above mentioned points, the design looks ok to me.
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Updated (by Guest): Add a mysqlbinlog option to change the used database (36)
Alexi1952 alexi1...@yandex.ru writes:
PS. I don't know company rules, so being currently a pre-member of Maria
(ha! I even don't know how the company is called)
I didn't send this reply to maria-developers@lists.launchpad.net. If that's
not right, I will do it.
You are welcome to use maria-developers@lists.launchpad.net for anything
related to development of MariaDB. We often have people also outside of Monty
Program that provide insightful comments on patches or discussions that catch
their interest. I've Cc:ed the list for now.
(Are you a member of maria-developers@ ? If not, you should be, apply on
https://launchpad.net/~maria-developers (or just let me know your Launchpad
login) and I will approve you.)
18.09.09, 17:29, Kristian Nielsen kniel...@knielsen-hq.org:
Hi Alexi,
Thanks for writing up the low-level design. I read it through, and have a
couple of comments:
1.3. In mysqlbinlog.cc:
- Add { rewrite-db, OPT_REWRITE_DB, ...} record to my_long_options:
- Add Rpl_filter object to mysqlbinlog.cc
Rpl_filter* binlog_filter;
Sharing code with similar replication options inside mysqld is a noble
goal. However, in this case I think it is a case of the cure is worse than
the disease.
The Rpl_filter class has _so_ much mysqld server internals that we do not
want
to mix into a client application. That is also why you need to do all these
modifications in sql_list, rpl_filter, etc.
So I think it is wrong to use the Rpl_filter class in mysqlbinlog.
To share code between the two, I think the better method is to move out the
needed functionality (add_db_rewrite() and get_rewrite_db()) in a separate
class, and have both the Rpl_filter class and mysqlbinlog use that.
Alternatively, if the shared functionality is really small (as it appears it
might be), just duplicating the functionality may be better.
***
Funny: in my first version I wrote my own simple list-class with add() and
get()
functions (what is really needed here) and was scarified by SPetrunia for
why
didn't I use Rpl_filter. :) His idea was that mysqlbinlog options should be
Right, sharing the code is best, hence the idea to extract common
functionality in a separate class.
In particular, I do not like this method of Rpl_filter:
bool tables_ok(const char* db, TABLE_LIST* tables);
TABLE_LIST is deep deep into server internals, that is why I didn't like
pulling Rpl_filter as it is now into mysqlbinlog.
But actually Rpl_filter::tables_ok() seems to be the only problem of this kind
in Rpl_filter. So probably we just need to move this single method out into a
separate class (or existing class or static function, didn't check which would
be most appropriate). That method feels misplaced in that class to me.
So an Rpl_filter class without tables_ok() I see no problem with including in
mysqlbinlog. That would seem to me much cleaner, and should be simple, what
do you think?
processed in the same manner as for replication.
I had two reasons for using the very Rpl_filter:
1. It already contains add_db_rewrite() and get_rewrite_db() functions which
are exactly what is needed.
2. I had in my mind WL40 (Add a mysqlbinlog option to filter updates to
certain tables) for which also I saw needed function in Rpl_filter.
Yes, I agree that these are good reasons.
But frankly speaking, I looked through Rpl_filter code not-deeply - just to
be sure that two mentioned function do what exactly I need and to get an
impression that other functions looks like appropriate for options mentioned
in WL40. I need to examine this more closely to take a final decision and/or
to continue discussing with you on this point. Nevertheless, just few notes:
Note 1. In any case, I like the idea of a separate class.
(But see the objection in Note 2 which may be applied to rpl_filter
as well).
Note 2. Please note that, essentially, modifications touches only sql_list -
not Rpl_filter. As I noticed there several generally used classes
(lists is just one example) which are bound to the server context only
because of using the sql_alloc() function in new-operator(s). This
function returns MEM_ROOT pointer attached to the current thread and
because of that is server-dependent. But why not - with the help of
just two-three #ifdef's - to make this classes server-independent?
Why not to allow sql_list to be used outside server context especially
in view of that sql_list essentially (i.e. functionally) is not server
dependent?
Surely, I can foresee at least one reasonable objection: because these
classes strictly belong to the server internals and are not supposed
to be used outside. That's OK. But they can be used outside
INDIRECTLY.
Thus starting to work on embedded parser (currently, my
Re: [Maria-developers] negative TIME in SHOW FULL PROCESSLIST and information_schema.processlist
Henrik Ingo henrik.i...@avoinelama.fi writes: I'm the wrong person to answer, but seems to me we should at this stage prefer being bug-for-bug compatible and changing semantics between MariaDB and MySQL may turn out to be more of a problem than being helpful. (If we could agree with the MySQL team to adopt the fix in a future version, it would be different.) Compatibility is a valid point, but we must also be very careful not to fall into the trap of not daring to do changes that make sense. So we need balance. If we stop fixing bugs or bad behaviour then I think we have made ourselves irrelevant. In this case, the problem is that we add another column. So we have two time columns, one in whole seconds (for compatibility) and one in fractional milliseconds. And I think it is really confusing if these two columns sometimes differ widely from each other. Hence the need for a carefully thought out decision. Thanks, - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] negative TIME in SHOW FULL PROCESSLIST and information_schema.processlist
Henrik Ingo henrik.i...@avoinelama.fi writes: Where else would @@TIMESTAMP be modified? Can a user do that from SQL? Yes (or @TIMESTAMP at least).. mysql set TIMESTAMP=100; Query OK, 0 rows affected (0.00 sec) mysql select now(); +-+ | now() | +-+ | 1970-01-01 01:01:40 | +-+ 1 row in set (0.00 sec) mysql show full processlist; ++--+---+--+-++---+---+ | Id | User | Host | db | Command | Time | State | Info | ++--+---+--+-++---+---+ | 15 | root | localhost | test | Query | 1253605187 | NULL | show full processlist | ++--+---+--+-++---+---+ 1 row in set (0.00 sec) (If so, why???) Loading mysqlbinlog output, testing, ... and confusing SHOW FULL PROCESSLIST :-) Thanks, - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Updated (by Guest): Add a mysqlbinlog option to change the used database (36)
Alexi1952 alexi1...@yandex.ru writes:
Agree. BTW tables_ok() is just the only member I had already #ifdef'ed out
from Rpl_filter for client context.
Ah, I see.
As for your suggestion to have a separate class, is it OK to do something
like this?
class Binlog_filter
{
... all members from Rpl_filter except for tables_ok()
... (will also check carefully for other members) ...
};
class Rpl_filter: public Binlog_filter
{
... tables_ok() ...
};
Yes, that sounds good.
BTW in this case declaring
Binlog_filter* binlog_filter;
will look like more natural than
Rpl_filter* binlog_filter;
(why indeed *replication filter* in mysqlbinlog which actully *doesn't
replicate* :)
Indeed :-)
Thanks,
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
[Maria-developers] Information for release notes
Hi Daniel, Here is a rough changelog written from reading through bzr history. I took a dump of every commit in MariaDB that is not in MySQL 5.1.38, and wrote this summary of the changes. I don't have sufficient knowledge to parse through all of the Maria changes from before MariaDB started. Instead I wrote a generic entry for the Maria storage engine, and also added entries for what is already written (by Monty I think) on http://askmonty.org/wiki/index.php/MariaDB_versus_MySQL So this is probably the best shot we have at a complete list of relevant differences between MySQL and MariaDB. Do let me know if anyone finds anything missing or any errors. Daniel, I hope you can use this as the basis for the release notes. Maybe this list will also be useful for you to fill out the Manual on the Wiki. I am thinking you could check that all new features are documented, and add pages for those that are not. If not trivial, you could just make a stub page and ask on maria-developers@ for someone to fill them out? - Kristian. --- Generally: MariaDB-5.1.38-beta1 is based on MySQL-5.1.38, but has these additional features and bug fixes. Feature: mysql-test-run now has options --stop-file and --stop-keep-alive (also accessible with environment variables MTR_STOP_FILE and MTR_STOP_KEEP_ALIVE). With these, it is possible to pause a running test temporarily and let it continue later. Bug fix: mysqlslap: setting --engine does not get replicated http://bugs.mysql.com/bug.php?id=46967 mysqlslap: specifying --engine and --create does not work with --engine=storage_engine:option https://bugs.launchpad.net/maria/+bug/429773 Feature: Improvements to Gcov support in testing. Feature: New column TIME_MS in SHOW FULL PROCESSLIST and INFORMATION_SCHEMA.PROCESSLIST, similar to the old TIME column, but with microsecond resolution. Also fixes old TIME column to not be influenced by @TIMESTAMP. Patch by Percona. Bug fix: rpl_do_grant fails on PB-2 with a failing connect http://bugs.mysql.com/bug.php?id=47016 Bug fix: Windows: mysql-test-run --log-error fixed to not add --console. Bug fix: The myisam_crash_before_flush_keys test fails on Windows http://bugs.mysql.com/bug.php?id=47455 Bug fix: rpl.rpl_get_master_version_and_clock fails on hpux11.31 http://bugs.mysql.com/bug.php?id=46931 Bug fix: safe_process: FATAL ERROR, Unknown option: --nocore http://bugs.mysql.com/bug.php?id=46212 Feature: Optimizer improvement: Table elimination. http://askmonty.org/worklog/Server-Sprint/?tid=17 Bug fix: XtraDB crashes on startup on windows https://bugs.launchpad.net/maria/+bug/417751 Bug fix: Eliminate compiler warnings. Bug fix: Fix parsing of enum-valued options for plugins. https://bugs.launchpad.net/maria/+bug/423035 Feature: Enhancements to slow log. Includes details of execution plan and microsecond-precision resolution. Based on microslow patch by Percona. Feature: PBXT storage engine. PBXT is developed by PrimeBase Technologies, http://www.primebase.org/ Bug fix: Solaris build fixes. Feature: XtraDB storage engine as a replacement for the MySQL built-in InnoDB. XtraDB is based on the Oracle/Innobase InnoDB plugin version 1.0.3, with enhancements. XtraDB is developed by Percona. Feature: Performance improvements for common cases of character set conversion. Feature: Pool-of-threads, allowing to map a high number of simultaneous connections onto a lower number of operating system treads, to reduce overhead with using large number of threads. Feature: New handler call prepare_index_scan() and other small improvements to the internal storage engine handler API. Bug fix: query_cache_debug.test fails http://bugs.mysql.com/bug.php?id=45632 Bug fix: enum-style command-line options are not honoured (maria.maria-recover fails) http://bugs.mysql.com/bug.php?id=41010 Bug fix: mysql-test-run sometimes terminated mysqld early, causing loss of memory leak error reports from Valgrind and GCov test coverage output. http://bugs.mysql.com/bug.php?id=43418 Bug fix: Several Valgrind reported bugs in the source code fixed. Bug fix: Save SAFE_MUTEX configure #define in config.h, to facilitate correct build options for plugins. Feature: ./configure now outputs a summary section at the end of the output. (By C.J. Adams-Collier). Bug fix: test maria.maria fails if server built without '--with-partition' https://bugs.launchpad.net/maria/+bug/330611 Feature: NDB storage engine disabled in MariaDB builds. (NDB is not supported in MariaDB). Feature: Added --abort-source-on-error to the mysql client. Feature: Faster CHECKSUM TABLE. Feature: Debugging code to check for taking mutexes in the wrong order,
Re: [Maria-developers] automake fixes for maria 5.1
Peter Lieverdink pe...@openquery.com writes: I've been working on creating packaging scripts for Maria on Debian/Ubuntu and came across a few issues with the automake scripts. They are basically all related to the use case where srcdir != builddir - as is the case in the debian foo. My changes are on launchpad; in https://code.launchpad.net/~ourdelta-core/maria/maria-5.1-automakefixes I've submitted this branch for merging back into maria/maria-5.1-merge. Thanks a lot! I pushed the merge into maria-5.1-merge. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] WL40: Notes/questions
Alexi1952 alexi1...@yandex.ru writes:
Hi Alexi! Sorry for the delay in answering, things have been quite busy...
With WL36 and WL40 we have:
mysqlbinlog options:
--database=db
--rewrite-db=db_from-db_to
--do-table=db.tbl
--ignore-table=db.tbl
--wild-do-table=pattern.pattern
--wild-ignore-table=pattern.pattern
replication options:
--replicate-rewrite-db=db_from-db_to
--replicate-do-db=db
--replicate-ignore-db=db
--replicate-do-table=tbl
--replicate-ignore-table=tbl
--replicate-wild-do-table=db.tbl
--replicate-wild-ignore-table=db.tbl
1. In mysqlbinlog we do not have --do_db and --ignore_db options.
Does it mean that instead it is supposed to use:
--replicate-wild-do-table=db.%
--replicate-wild-ignore-table=db.%
respectively?
I think the --database option of mysqlbinlog is supposed to be similar to
mysqldump of a particular database, rather than similar to replication.
Compared with other options, --database option looks like
a foreign body :
- contrary to other options, it allows to specify only one
database (with multiple --database's only the last one is
used);
- having with --database an analog of do_db, we have no
similar analog of ignore_db.
2. In replication two functions are used for filtering databases:
- db_ok(const char* db) which matches db only with do-db and
ignore-db rules;
- db_ok_with_wild_table(const char* db) which matches db only
with wild-do-table=db.% and wild-ignore-table=db.% rules.
This function is applied only to CREATE DB, DROP DB, and
ALTER DATABASE statements.
In mysqlbinlog, should we follow the same scheme, namely:
- db_ok() for matching db with --database option only;
- db_ok_with_wild_table() for statements listed above?
It is a bit of a complex issue, but your suggestion sounds reasonable.
3. According to replication filtering rules, --replicate-rewrite_db
is always done _before_ other --replicate-* rules are tested;
see explanation for --replicate-rewrite-db in RefMan (16.1.3.3.
Replication Slave Options and Variables), or the following piece
of code in og_event.cc:
int Table_map_log_event::do_apply_event(Relay_log_info const* rli)
{
RPL_TABLE_LIST* table_list;
...
strmov(table_list-db, rpl_filter-get_rewrite_db(m_dbnam,
dummy_len));
...
if (...!rpl_filter-db_ok(table_list-db) ...)
...
}
And what about --database + rewrite-db for mysqlbinlog? If we mean to
output only database xxx with renaming it to yyy, should we use
(1) mysqlbinlog --database=xxx --rewrite-db=xxx-yyy
or
(2) mysqlbinlog --database=yyy --rewrite-db=xxx-yyy
In current WL36 design it is supposed that (1) should be used
(surely, this can easily be redesigned). But this becomes confused
with using of --wild-do-table + replication filtering rules,
for which we should use:
(3) --wild-do-table=yyy.% --rewrite-db=xxx-yyy
Personally, I think it makes more sense to apply the filter before the rewrite
in mysqlbinlog. Even though this is different from how replication works. (2)
and (3) appear quite confusing (to the user).
I think the difference is that with replication, the
--replicate-[wild-]{do,ignore}-table options concern how the binlog is
_applied_. So it makes sense (maybe) to rewrite the events first, and then
apply them (since the other way around is impossible).
But with mysqlbinlog we are not applying events, only filtering. So I think it
makes more sense for filtering rules to apply to the name before rewriting.
We can't change replication to do filtering before rewriting, which leaves it
inconsistent with mysqlbinlog according to this. But instead we could use
different names for the options, as I think the -do- implies actually applying
the events rather than filtering.
So maybe
--include-table
--exclude-table
--wild-include-table
--wild-exclude-table
and these (and --database) are done before rewrite. And the --wild-* forms
should be sufficient for more complex database filtering (so no need for
options similar to --replicate-{do,ignore}-db).
At least that's my immediate opinion.
Good analysis BTW!
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] WL40: Notes/questions
Arjen Lentz ar...@openquery.com writes: Current - the binlog options prevent things from getting logged locally, which is bad for point-in-time recovery. - the replicate options work on the slave end, so they still get transmitted which is a) slow and b) potential security issue. Yes. So we filter either when generating the event or when applying the event. Whereas the better place to filter would be when sending to slave. Of course, filtering when generating and/or applying is significantly easier, especially for statement-based replication. Since it is at those points we have a parsed statement available. At send-to-slave time we only have the currently selected database, and parsing each statement before sending to each slave may not be the right solution. Filtering on current database (or on whatever for row-based) might be more feasible, though there would still be the additional overhead of decoding each event before sending to each slave. But it is good to keep in mind that the general problem has wider scope, thanks for your comment! (In this worklog we are looking at mysqlbinlog, not replication, and this discussion helps clarify why we may want different options in mysqlbinlog from in current replication). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Updated (by Guest): Add a mysqlbinlog option to change the used database (36)
worklog-nore...@askmonty.org writes: -=-=(Guest - Sat, 03 Oct 2009, 02:27)=-=- High-Level Specification modified. --- /tmp/wklog.36.old.23366 2009-10-03 02:27:45.0 +0300 +++ /tmp/wklog.36.new.23366 2009-10-03 02:27:45.0 +0300 @@ -1,77 +1 @@ -Context -(See http://askmonty.org/wiki/index.php/Scratch/ReplicationOptions for global -overview) -At the moment, the server has a replication slave option - - --replicate-rewrite-db=from-to [snipped more deletion of content] +G9m7yq a href=http://ijfmyyjtveuu.com/;ijfmyyjtveuu/a, [url=http://jeczeaqoxbpt.com/]jeczeaqoxbpt[/url], [link=http://nrisgrrvcrkm.com/]nrisgrrvcrkm[/link], http://edmnozsmotmt.com/ I have fixed this vandalism. But if this continues, it looks like we will have to restrict all Worklog updates to registrered developers :-( - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Windows buildslaves: suggestion for remedy of 'exception' failures.
Sergey Petrunya pser...@askmonty.org writes:
Hi!
Both mine and Bo's buildslave are prone to error conditions like this:
http://askmonty.org/buildbot/builders/win32-rel-nmake/builds/19/steps/bzr/logs/err.html
Here is a suggestion on how to eliminate those.
Buildslave setup
Buildslave owner needs to download pstools and handle utilites:
http://technet.microsoft.com/en-us/sysinternals/bb896683.aspx
http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx
they need to unpack the zips, then put handle.exe, pskill.exe, pdh.dll
somwhere
on the path, and then run both exe files manually. The first manual run is
needed to accept the EULA.
Buildbot script
---
I've come up with this script that uses the above utilities to kill all stray
processes:
#!/usr/bin/perl
my $cmd=handle.exe maria-slave | ;
(I guess maria-slave should be $ARGV[0] or something ...)
open(IN, $cmd) || die(Failed to pipe from handle.exe);
my @pids = ();
print $cmd\n;
while(IN) {
print $_;
if (/ pid: ([0-9]+) /) {
push @pids, $1;
}
}
close(IN);
print \n\n;
my %hash = map { $_ = 1} @pids;
my @uniq_pids = keys %hash;
foreach (@uniq_pids) {
$cmd= pskill.exe $_\n;
print $cmd;
system($cmd);
}
EOF
The question is, where do we put the script? Have buildslave owners put it on
the slaves manually (bad, complicates the setup)? Download through buildbot?
Downloading through buildbot should work well actually, it has easy-to-use
support for that.
Any comments?
Let's try it.
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] A mess with sql_alloc() ?
Alexi1952 alexi1...@yandex.ru writes:
Thanks for your comments!
In any case extern declarations like this should be avoided, much better to
only have the declaration in one place in some *.h file.
I agree. Currently, we have:
mysql_priv.h:
#ifndef MYSQL_CLIENT
...
void *sql_alloc(size_t);
...
#endif
thr_malloc.cc:
void *sql_alloc(size_t Size)
{
MEM_ROOT *root= *my_pthread_getspecific_ptr(MEM_ROOT**,THR_MALLOC);
return alloc_root(root,Size);
}
This states that sql_alloc() *should not* be used in MYSQL_CLIENT context
(hence all these extern declarations). In my opinion, it's more correctly to
have:
mysql_priv.h:
void *sql_alloc(size_t);
thr_malloc.cc:
#ifndef MYSQL_CLIENT
void *sql_alloc(size_t Size)
{
MEM_ROOT *root= *my_pthread_getspecific_ptr(MEM_ROOT**,THR_MALLOC);
return alloc_root(root,Size);
}
#endif
which states instead that sql_alloc() *can be* used in a client context
but should be supplied with *another definition*.
Yes, agree.
Question: May I do these changes in mysql_priv.h and thr_malloc.cc ?
On the one hand, it is resonable. On the other hand, I am confused a bit
with mysql_priv.h name intended to mean that content of this file belongs
to mysql internals (though this file is included in mysqlbinlog.cc)
I think this is ok to do (I will check them again when I see the patch for
review).
It is true about mysql_priv.h being more internal, but then mysqlbinlog
already goes deep deep into internals (the replication event stuff).
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Buildbot scheduling problem: makedist waiting for newtest
Sergey Petrunya pser...@askmonty.org writes: One can now frequently observe buildbot to be in this state: hardy-amd64-makedist (idle with 1 pending) hardy-amd64-newtest (building with 1 pending) I interpret it as follows: makedist is waiting for newtest to complete. The problem with that is that when one is working on a windows problem, he has to wait for newtest to complete for every push. Yes. Both are running on the same machine (in my office). So far, it was configured to only run one build at a time. The only was I see to fix this is to have a dedicated buildslave for makedist jobs, i.e. with current settings hardy should run two buildslaves, one working on makedist and the other on newtest. Is there a better way to address this? I think Buildbot allows to run multiple builds in parallel on a single slave. I configured my box to allow two simultaneous builds. We will see if it can handle the load (on of them runs --big tests, which can make quite a load on a machine). (I was planning to try this anyway after putting more memory into the box; good that you reminded me). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] request for comment: OQGRAPH in 5.1 packages
Arjen Lentz ar...@openquery.com writes: packages before they will try things. If 5.1 binaries had had PBXT plugin sitting there, lots more people would have tried it earlier, filed bugreports and feedback, and Paul would have been where he is now much quicker. With MariaDB pulling it in it's ok now, but it's just a darn waste and pity of the earlier time. I also think this is a very clear description of an important point. ++ (On the practical side, since it's essentially separate it would get added during the source tarball prep in the builds, so no action required inside the maria tree) It is _much_ better to get it inside the tree. Everything in MariaDB development revolves around the bzr tree. Development, buildbot, testing etc. etc. If it's not in the tree, it will be broken by some MariaDB change. And you will discover it only during release work. And we will have to delay the release or omit ograph from that release, and generally waste lots of time and effort. And you will be on your own to fix things. If it's in the tree we will catch problems immediately and have the longest possible time to plan and fix. Of course it's your code so it's your call in the end. But I just don't understand why you would _not_ want it in the tree. Is there some specific concern(s) that we could perhaps address? We can use bzr merge-into (like with xtradb) so you can still maintain a stand-alone tree. We accept storage engines like this into the tree without any copyright assignment, just the GPL 2 is fine. I know I'm preaching in-tree and Buildbot to you all the time :-). But it really is the way development needs to be done to scale to the level we want and utilise the limited resources we have. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] request for comment: OQGRAPH in 5.1 packages
Arjen Lentz ar...@openquery.com writes:
We filed a wishlist bug for this,
https://bugs.launchpad.net/maria/+bug/470580 which also includes a
patch by Antony Curtis. It creates a mysql-
glob.h during the build process, which we could put into a mariadb-
plugin-dev package.
Then, some mariadb- packages can be build in the main mariadb
build, and some can be separate.
It also allows developers to work on plugins sanely. It cleans up the
entire dev environment for this - it's not 100% pretty as it's a nasty
big include, but it's a good step given the current mess.
I took a look at this (sorry for slight delay, have been swamped with lots of
small tasks the last couple of days).
I very much agree with the idea of having a plugin-dev package that is
sufficient for building plugins. It seems it should be doable with not too
much work.
I know we already did some fixes in the MariaDB tree to make this
possible. Basically some configure/CFLAGS options could affect the binary
interface (think it was DEBUG / SAFEMALLOC flags). These were moved into
config.h so that it is not necessary to guess the right values of these
options to build a plugin that will load without crashing.
We can do more of these kinds of fixes as needed.
I do not understand the approach taken in the patch though. Seems to me to be
the wrong approach? Though I could be misunderstanding, the patch doesn't
contain much in the way of explanation / comments yet.
So I was expecting to see somthing that collected a set of include files
needed to build (storage engine) plugins, and putting them somewhere plugins
could reference them.
Instead, the patch seems to run the C pre-processor on mysql_priv.h, I assume
to get a _single_ .h file with everything? And the result is passed through
some Perl filter and munged in various interesting ways.
So I guess my first question is why to do it this roundabout way at all? Why
not just collect the necessary .h files? Seems much cleaner, simpler, easier
to maintain, etc. If there are some issues with this, maybe we could instead
fix these issues in the source?
Thanks,
- Kristian.
=== modified file 'sql/Makefile.am'
--- old/sql/Makefile.am 2009-09-15 10:46:35 +
+++ new/sql/Makefile.am 2009-11-02 09:19:32 +
@@ -20,6 +20,7 @@
MYSQLBASEdir=$(prefix)
MYSQLLIBdir=$(pkglibdir)
pkgplugindir = $(pkglibdir)/plugin
+globincldir =$(pkgincludedir)/mysql/$(VERSION)
INCLUDES = @ZLIB_INCLUDES@ \
-I$(top_builddir)/include -I$(top_srcdir)/include \
-I$(top_srcdir)/regex -I$(srcdir) $(openssl_includes) \
@@ -29,6 +30,7 @@
libexec_PROGRAMS = mysqld
EXTRA_PROGRAMS = gen_lex_hash
bin_PROGRAMS = mysql_tzinfo_to_sql
+globincl_HEADERS = mysql-glob.h
noinst_LTLIBRARIES= libndb.la \
udf_example.la
@@ -179,6 +181,12 @@
./gen_lex_hash$(EXEEXT) $...@-t
$(MV) $...@-t $@
+mysql-glob.h:mysql_priv.h
+ $(CXXCPP) -x c++-header $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
+ $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) \
+ -CC -dDI $^ | $(PERL) $(srcdir)/make-mysql-glob.pl $...@-t
+ $(MV) $...@-t $@
+
# For testing of udf_example.so
udf_example_la_SOURCES= udf_example.c
udf_example_la_LDFLAGS= -module -rpath $(pkglibdir)
=== added file 'sql/make-mysql-glob.pl'
--- old/sql/make-mysql-glob.pl1970-01-01 00:00:00 +
+++ new/sql/make-mysql-glob.pl2009-11-02 09:39:43 +
@@ -0,0 +1,179 @@
+#!/usr/bin/perl
+
+use strict;
+
+my $current_file;
+my $current_line;
+my $current_path;
+
+my @command_line= ();
+
+my $until_file;
+my $until_line;
+
+my $last_include;
+
+my $echo= \echo_on;
+my $echo_line;
+
+my $first_define;
+my $define_suffix = sub { };
+
+sub canon($)
+{
+ my ($path)= @_;
+ my $tmp= $path;
+ $tmp =~ s@/[^/]+/\.\./@/@;
+ return canon($tmp) if $tmp ne $path;
+ return $path;
+}
+
+$first_define = sub {
+ my ($line) = @_;
+ if ($line =~ m/^#define\s+([^\s]+)/)
+ {
+my ($e,$d)= ($echo, $1);
+$first_define = sub { return 0; };
+$e(#ifndef MYSQL_GLOB_H\n#define MYSQL_GLOB_H\n#ifdef $d\n#error
cannot mix headers\n#endif\n$line\n);
+foreach (@command_line)
+{
+ $e($_);
+}
+
+$define_suffix= sub
+{
+ $e(#endif /* MYSQL_GLOB_H / $d */\n);
+};
+
+return 1;
+ }
+ return 0;
+};
+
+sub echo_on($)
+{
+ my ($line) = @_;
+
+ return if $first_define($line);
+ return if $line =~ m/^#define\s+SHOW_FUNC\s+/;
+
+ print $echo_line if defined $echo_line;
+ print $line;
+ undef $echo_line;
+}
+
+sub echo_off($)
+{
+ my ($line)= @_;
+ if (($current_file eq $until_file) ($current_line == $until_line))
+ {
+$echo= \echo_on;
+undef $until_file;
+undef $until_line;
Re: [Maria-developers] [Merge] lp:~percona-dev/percona-xtradb/fix-bug476887 into lp:~percona-dev/percona-xtradb/extensions-1.0
Aleksandr Kuzminsky aleksandr.kuzmin...@percona.com writes: Aleksandr Kuzminsky has proposed merging lp:~percona-dev/percona-xtradb/fix-bug476887 into lp:~percona-dev/percona-xtradb/extensions-1.0. Requested reviews: Percona developers (percona-dev) Related bugs: #476887 hardcoded PERCONA_INNODB_VERSION https://bugs.launchpad.net/bugs/476887 When one compiles XtraDB from sources he has to pass -DPERCONA_INNODB_VERSION=9 in AM_CPPFLAGS. 9 is an XtraDB version here. Otherwise innodb_version will be 1.0.4-unknown Does this have any impact on how XtraDB is built when built as part of MariaDB? Is there something we should change in how things work when we merge this into MariaDB? - Kristian. -- https://code.launchpad.net/~percona-dev/percona-xtradb/fix-bug476887/+merge/14570 You are subscribed to branch lp:~percona-dev/percona-xtradb/extensions-1.0. === modified file 'innodb_show_status.patch' --- innodb_show_status.patch 2009-09-03 08:25:21 + +++ innodb_show_status.patch 2009-11-06 23:45:22 + @@ -157,32 +157,37 @@ #ifndef UNIV_NONINL #include thr0loc.ic #endif -diff -ru innodb_plugin-1.0.4_orig/include/univ.i innodb_plugin-1.0.4_tmp/include/univ.i innodb_plugin-1.0.4_orig/include/univ.i 2009-07-21 06:56:30.0 +0900 -+++ innodb_plugin-1.0.4_tmp/include/univ.i 2009-08-28 15:33:48.0 +0900 -@@ -47,6 +47,7 @@ - #define INNODB_VERSION_MAJOR1 +diff -Nur a/include/univ.i b/include/univ.i +--- a/include/univ.i 2009-11-06 12:57:14.0 -0800 b/include/univ.i 2009-11-06 13:02:43.0 -0800 +@@ -48,6 +48,11 @@ #define INNODB_VERSION_MINOR0 #define INNODB_VERSION_BUGFIX 4 -+#define PERCONA_INNODB_VERSION 7 ++#ifndef PERCONA_INNODB_VERSION ++#define PERCONA_INNODB_VERSION unknown ++#endif ++ ++ /* The following is the InnoDB version as shown in SELECT plugin_version FROM information_schema.plugins; -@@ -58,13 +59,14 @@ + calculated in in make_version_string() in sql/sql_show.cc like this: +@@ -58,13 +63,15 @@ (INNODB_VERSION_MAJOR 8 | INNODB_VERSION_MINOR) /* auxiliary macros to help creating the version as string */ -#define __INNODB_VERSION(a, b, c) (#a . #b . #c) -#define _INNODB_VERSION(a, b, c)__INNODB_VERSION(a, b, c) -+#define __INNODB_VERSION(a, b, c, d)(#a . #b . #c - #d) -+#define _INNODB_VERSION(a, b, c, d) __INNODB_VERSION(a, b, c, d) ++#define __INNODB_VERSION(a, b, c, d) (#a . #b . #c - #d) ++#define _INNODB_VERSION(a, b, c, d)__INNODB_VERSION(a, b, c, d) ++ #define INNODB_VERSION_STR \ _INNODB_VERSION(INNODB_VERSION_MAJOR, \ INNODB_VERSION_MINOR, \ -INNODB_VERSION_BUGFIX) -+INNODB_VERSION_BUGFIX, \ -+PERCONA_INNODB_VERSION) ++INNODB_VERSION_BUGFIX, \ ++PERCONA_INNODB_VERSION) #define REFMAN http://dev.mysql.com/doc/refman/5.1/en/; ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] storage engine typecode problem?
Arjen Lentz ar...@openquery.com writes: Getting this in MariaDB 5.1.39 builds: 091109 4:41:43 [Warning] Storage engine 'FEDERATED' has conflicting typecode. Assigning value 42. Thanks for the notice; I pushed a fix (by Monty) for this into 5.1-release. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Go for MariaDB 5.1.39 release
I pushed the final fixes, including the merge of XtraDB, into the release branch: lp:~maria-captains/maria/5.1-release I tagged the latest revision with the tag tag:mariadb-5.1.39-beta Daniel, for the release notes please mark that this release is based on MySQL 5.1.39 and XtraDB 8 (which has InnoDB plugin 1.0.4 as base). Arjen, we are now go for final release build. Hopefully we can be ready for release Tuesday, which according to my information would allow Monty to announce the release at OpenSQL Camp. You can use tarbake51/sh tag:mariadb-5.1.39-beta lp:~maria-captains/maria/5.1-release to be 100% sure to grab the right revision for the release (or whatever variant fits your build infrastructure best). There is still the mysql_client_test failure on Ubuntu 9.10 Karmic. We need to fix this for the next MariaDB 5.1.41 release. There are also other failures seen in Buildbot, including - A number of sporadic test failures that occur only occasionally. - Windows test failures. - Solaris build failure and Mac test failures. - Test failures on non-max builds. For these reasons I think it is correct to still call this release only a Beta. We should fix these issues for 5.1.41, and if no serious new issues are reported on 5.1.39 I think we can plan for 5.1.41 to be a release candidate. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Test failures in PBXT after merging with MySQL-5.1.41
Hi Paul, Vladimir, We are working on merging latest MySQL (5.1.41) into MariaDB. After the merge, I see some test failures in the PBXT test suite. See here: https://askmonty.org/buildbot/builders/hardy-amd64-fulltest/builds/118/steps/test_2/logs/stdio Or if you prefer, see here for a search for these failures in the build history database: http://askmonty.org/buildbot/reports/cross_reference#branch=5.1-mergerevision=2768platform=hardy-amd64-fulltestdt=bbnum=typ=info=fail_name=pbxt.fail_variant=fail_info_short=fail_info_full= From a quick look, it seems to me most/all of these are just the need to adjust result files for changes/bugfixes in MySQL. But before spending time on fixing, I though it was better to coordinate with you, to not duplicate effort. So perhaps you already did the similar changes for the PBXT testsuite against MySQL 5.1.41? Is there maybe a newer version of PBXT that we should merge? Or alternatively, do you want me to fix the testsuite, and then send you a patch for merging into PBXT to update to 5.1.41? - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Test failures in PBXT after merging with MySQL-5.1.41
Kristian Nielsen kniel...@knielsen-hq.org writes: Paul McCullagh paul.mccull...@primebase.org writes: You are welcome to make the changes to the PBXT tests. For the PBXT trunk we are still using 5.1.35 for testing, but this should not be a problem. Ok, will do, I will send you a link to the patch/commit. Here it is: https://lists.launchpad.net/maria-developers/msg01535.html - Kristian. PS. I now get this in the mysqld.err log after server shutdown in PBXT test suite: 091124 13:09:45 [Warning] Plugin 'MyISAM' will be forced to shutdown 091124 13:09:45 [Warning] Plugin 'PBXT' will be forced to shutdown Do you know anything about what this means? Is it a problem to be fixed, or just a harmless warning caused by the test suite framework? - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Test failures in PBXT after merging with MySQL-5.1.41
Kristian Nielsen kniel...@knielsen-hq.org writes: PS. I now get this in the mysqld.err log after server shutdown in PBXT test suite: 091124 13:09:45 [Warning] Plugin 'MyISAM' will be forced to shutdown 091124 13:09:45 [Warning] Plugin 'PBXT' will be forced to shutdown Ok, some more details: I can repeat this by running an empty test case (mysql-test/suite/pbxt/t/kn.test): -- cut here -- --skip Test shutdown problem with skipped test -- cut here -- (cd mysql-test perl mysql-test-run.pl --suite=pbxt pbxt.kn) I get this in the mysqld.1.err: CURRENT_TEST: pbxt.kn 091124 15:11:00 [Note] Plugin 'InnoDB' is disabled. 091124 15:11:00 [Note] PrimeBase XT (PBXT) Engine 1.0.08d RC loaded... 091124 15:11:00 [Note] Paul McCullagh, PrimeBase Technologies GmbH, http://www.primebase.org 091124 15:11:00 [Note] Event Scheduler: Loaded 0 events 091124 15:11:00 [Note] /home/knielsen/devel/maria/my/merge-5.1.41/sql/mysqld: ready for connections. Version: '5.1.41-mariadb-beta-valgrind-max-debug-log' socket: '/home/knielsen/devel/maria/my/merge-5.1.41/mysql-test/var/tmp/mysqld.1.sock' port: 13000 Source distribution 091124 15:11:00 [Note] Got signal 15 to shutdown mysqld 091124 15:11:00 [Note] /home/knielsen/devel/maria/my/merge-5.1.41/sql/mysqld: Normal shutdown 091124 15:11:00 [Note] Event Scheduler: Purging the queue. 0 events 091124 15:11:00 [Warning] Plugin 'MyISAM' will be forced to shutdown 091124 15:11:00 [Warning] Plugin 'PBXT' will be forced to shutdown 091124 15:11:00 [Note] PrimeBase XT Engine shutdown... 091124 15:11:00 [Note] Debug sync points hit: 50 091124 15:11:00 [Note] Debug sync points executed: 0 091124 15:11:00 [Note] Debug sync points max active per thread: 0 091124 15:11:00 [Note] /home/knielsen/devel/maria/my/merge-5.1.41/sql/mysqld: Shutdown complete This is from this tree on Launchpad containing the merge with MySQL 5.1.41: lp:~maria-captains/maria/5.1-merge The problem is that the ref_count of PBXT is 2 at shutdown time. Maybe this is another problem with the way that PBXT has to do init in a separate thread, I see you already had to solve some other possibly related problems. Any ideas? It may be that this is something introduced in the merge with MySQL 5.1.41, not 100% sure though as this particular warning was not detected before in our Buildbot tests... - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Test failures in PBXT after merging with MySQL-5.1.41
Kristian Nielsen kniel...@knielsen-hq.org writes: We are working on merging latest MySQL (5.1.41) into MariaDB. After the merge, I see some test failures in the PBXT test suite. See here: Ok, seems most of the PBXT failures are gone now. But one remains: http://askmonty.org/buildbot/reports/cross_reference#branch=5.1-mergerevision=platform=debian5-i386-fulltestdt=bbnum=typ=info=fail_name=pbxt.join_nestedfail_variant=fail_info_short=fail_info_full= (see end of mail for diff). It looks like the test is not deterministic, and chooses a slightly different execution plan between different test runs and platforms for the table t3 and t4. Do you have any suggestions about how to deal with this? - Kristian. CURRENT_TEST: pbxt.join_nested --- /var/lib/buildbot/maria-slave/debian5-i386-fulltest/build/mysql-test/suite/pbxt/r/join_nested.result 2009-11-25 21:10:35.0 +0300 +++ /var/lib/buildbot/maria-slave/debian5-i386-fulltest/build/mysql-test/suite/pbxt/r/join_nested.reject 2009-11-25 21:46:01.0 +0300 @@ -1008,13 +1008,13 @@ 1 SIMPLE t1 ALL NULL NULL NULL NULL 3 100.00 Using where; Using join buffer 1 SIMPLE t2 ALL NULL NULL NULL NULL 3 100.00 Using where 1 SIMPLE t3 ALL NULL NULL NULL NULL 2 100.00 Using where -1 SIMPLE t4 ref idx_b idx_b 5 test.t2.b 1 100.00 Using where +1 SIMPLE t4 ref idx_b idx_b 5 test.t2.b 1 100.00 1 SIMPLE t5 ALL idx_b NULL NULL NULL 3 100.00 Using where 1 SIMPLE t6 ALL NULL NULL NULL NULL 3 100.00 Using where 1 SIMPLE t7 ALL NULL NULL NULL NULL 2 100.00 Using where 1 SIMPLE t8 ref idx_b idx_b 5 test.t5.b 1 100.00 Using where 1 SIMPLE t9 ALL NULL NULL NULL NULL 3 100.00 Using where; Using join buffer -Note 1003 select `test`.`t0`.`a` AS `a`,`test`.`t0`.`b` AS `b`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t2`.`a` AS `a`,`test`.`t2`.`b` AS `b`,`test`.`t3`.`a` AS `a`,`test`.`t3`.`b` AS `b`,`test`.`t4`.`a` AS `a`,`test`.`t4`.`b` AS `b`,`test`.`t5`.`a` AS `a`,`test`.`t5`.`b` AS `b`,`test`.`t6`.`a` AS `a`,`test`.`t6`.`b` AS `b`,`test`.`t7`.`a` AS `a`,`test`.`t7`.`b` AS `b`,`test`.`t8`.`a` AS `a`,`test`.`t8`.`b` AS `b`,`test`.`t9`.`a` AS `a`,`test`.`t9`.`b` AS `b` from `test`.`t0` join `test`.`t1` left join (`test`.`t2` left join (`test`.`t3` join `test`.`t4`) on(((`test`.`t4`.`b` = `test`.`t2`.`b`) and (`test`.`t3`.`a` = 1))) join `test`.`t5` left join (`test`.`t6` join `test`.`t7` left join `test`.`t8` on(((`test`.`t8`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` 10 on(((`test`.`t7`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` = 2 on`test`.`t3`.`b` = 2) or isnull(`test`.`t3`.`c`)) and ((`test`.`t6`.`b` = 2) or isnull(`test`.`t6`.`c`)) and ((`test`.`t5`.`b` = `test`.`t0`.`b`) or isnull(`test`.`t3`.`c`) or isnull(`test`.`t6`.`c`) or isnull(`test`.`t8`.`c`)) and (`test`.`t1`.`a` 2))) join `test`.`t9` where ((`test`.`t9`.`a` = 1) and (`test`.`t1`.`b` = `test`.`t0`.`b`) and (`test`.`t0`.`a` = 1) and ((`test`.`t2`.`a` = 4) or isnull(`test`.`t2`.`c`)) and ((`test`.`t3`.`a` 5) or isnull(`test`.`t3`.`c`)) and ((`test`.`t4`.`b` = `test`.`t3`.`b`) or isnull(`test`.`t3`.`c`) or isnull(`test`.`t4`.`c`)) and ((`test`.`t5`.`a` = 2) or isnull(`test`.`t5`.`c`)) and ((`test`.`t6`.`a` = 4) or isnull(`test`.`t6`.`c`)) and ((`test`.`t7`.`a` = 2) or isnull(`test`.`t7`.`c`)) and ((`test`.`t8`.`a` 1) or isnull(`test`.`t8`.`c`)) and ((`test`.`t9`.`b` = `test`.`t8`.`b`) or isnull(`test`.`t8`.`c`))) +Note 1003 select `test`.`t0`.`a` AS `a`,`test`.`t0`.`b` AS `b`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t2`.`a` AS `a`,`test`.`t2`.`b` AS `b`,`test`.`t3`.`a` AS `a`,`test`.`t3`.`b` AS `b`,`test`.`t4`.`a` AS `a`,`test`.`t4`.`b` AS `b`,`test`.`t5`.`a` AS `a`,`test`.`t5`.`b` AS `b`,`test`.`t6`.`a` AS `a`,`test`.`t6`.`b` AS `b`,`test`.`t7`.`a` AS `a`,`test`.`t7`.`b` AS `b`,`test`.`t8`.`a` AS `a`,`test`.`t8`.`b` AS `b`,`test`.`t9`.`a` AS `a`,`test`.`t9`.`b` AS `b` from `test`.`t0` join `test`.`t1` left join (`test`.`t2` left join (`test`.`t3` join `test`.`t4`) on(((`test`.`t4`.`b` = `test`.`t2`.`b`) and (`test`.`t3`.`a` = 1))) join `test`.`t5` left join (`test`.`t6` join `test`.`t7` left join `test`.`t8` on(((`test`.`t8`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` 10 on(((`test`.`t7`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` = 2 on`test`.`t3`.`b` = 2) or isnull(`test`.`t3`.`c`)) and ((`test`.`t6`.`b` = 2) or isnull(`test`.`t6`.`c`)) and ((`test`.`t5`.`b` = `test`.`t0`.`b`) or isnull(`test`.`t3`.`c`) or isnull(`test`.`t6`.`c`) or isnull(`test`.`t8`.`c`)) and (`test`.`t1`.`a` 2))) join `test`.`t9` where ((`test`.`t9`.`a` = 1) and (`test`.`t1`.`b` = `test`.`t0`.`b`) and (`test`.`t0`.`a` = 1) and ((`test`.`t2`.`a` = 4) or isnull(`test`.`t2`.`c`)) and ((`test`.`t3`.`a` 5) or isnull(`test`.`t3`.`c`)) and ((`test`.`t3`.`b` = `test`.`t4`.`b`) or isnull(`test`.`t3`.`c`) or isnull(`test`.`t4`.`c`)) and ((`test`.`t5`.`a` = 2) or isnull(`test`.`t5`.`c`)) and ((`test`.`t6`.`a` = 4) or isnull
[Maria-developers] Help with memory leak in EXPLAIN
Hi Sergey,
I encountered a memory leak while working on fixing the MySQL 5.1.41 merge.
The memory leak is repeatable with the following test case:
-- cut here --
#
# Bug#45989 memory leak after explain encounters an error in the query
#
CREATE TABLE t1(a LONGTEXT);
INSERT INTO t1 VALUES (repeat('a',@@global.max_allowed_packet));
INSERT INTO t1 VALUES (repeat('b',@@global.max_allowed_packet));
--error ER_BAD_FIELD_ERROR
EXPLAIN SELECT DISTINCT 1 FROM t1,
(SELECT DISTINCTROW a AS away FROM t1 GROUP BY a WITH ROLLUP) as d1
WHERE t1.a = d1.a;
DROP TABLE t1;
-- cut here --
perl mysql-test-run.pl --valgrind kn.test
Errors/warnings were found in logfiles during server shutdown after running the
following sequence(s) of tests:
main.kn
==14709== 1,048,584 bytes in 1 blocks are possibly lost in loss record 7 of 7
==14709==at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
==14709==by 0xB1DDD0: my_malloc (my_malloc.c:37)
==14709==by 0x6691C1: String::real_alloc(unsigned) (sql_string.cc:43)
==14709==by 0x5D7BFF: String::alloc(unsigned) (sql_string.h:210)
==14709==by 0x669835: String::copy(String const) (sql_string.cc:192)
==14709==by 0x7E8BB0: do_save_blob(Copy_field*) (field_conv.cc:296)
==14709==by 0x7E6922: do_copy_null(Copy_field*) (field_conv.cc:207)
==14709==by 0x6EB28B: copy_fields(TMP_TABLE_PARAM*) (sql_select.cc:15374)
==14709==by 0x6F7F1B: end_write_group(JOIN*, st_join_table*, bool)
(sql_select.cc:12715)
==14709==by 0x6F4415: evaluate_join_record(JOIN*, st_join_table*, int)
(sql_select.cc:11514)
==14709==by 0x6F464E: sub_select(JOIN*, st_join_table*, bool)
(sql_select.cc:11399)
==14709==by 0x705B1E: do_select(JOIN*, ListItem*, st_table*, Procedure*)
(sql_select.cc:11155)
==14709==by 0x7161C2: JOIN::exec() (sql_select.cc:1809)
==14709==by 0x7127B6: mysql_select(THD*, Item***, TABLE_LIST*, unsigned,
ListItem, Item*, unsigned, st_order*, st_order*, Item*, st_order*, unsigned
long long, select_result*, st_select_lex_unit*, st_select_lex*)
(sql_select.cc:2425)
==14709==by 0x82EEEB: mysql_derived_filling(THD*, st_lex*, TABLE_LIST*)
(sql_derived.cc:294)
==14709==by 0x82EC8B: mysql_handle_derived(st_lex*, bool (*)(THD*, st_lex*,
TABLE_LIST*)) (sql_derived.cc:56)
This bug is also in main lp:maria MariaDB trunk, and also in current MySQL
(there is a MySQL bug, http://bugs.mysql.com/bug.php?id=45989).
Could you take a look, and see if it is something you/we could fix, or if you
have any other suggestions for how to deal with this?
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Plugin 'PBXT' will be forced to shutdown
Paul McCullagh paul.mccull...@primebase.org writes: I have seen this warning occasionally with other versions of MySQL. Since it also happens with MyISAM and sometimes other engines, I had not given it much thought before. As I understand it, the reason for the message about MyISAM is that PBXT is keeping references (directly or indirectly) to MyISAM. However, it would be good to track down exactly where this reference is being held. To repeat the error, do I just create an empty file called kn.test, and run: mysql-test-run.pl --suite=pbxt pbxt.kn No, the file should contain a single line as follows: -- cut here -- --skip Test shutdown problem with skipped test -- cut here -- (eg. this is a test that is always skipped). At least for me this allowed to repeat reliably. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (monty:2770)
Michael Widenius mo...@askmonty.org writes:
Monty, thaks a log for working on fixing all of these problems!
Below are some comments...
- Kristian.
#At lp:maria based on revid:mo...@askmonty.org-20091126201933-dgoynszp2z90gknl
2770 Michael Widenius2009-11-30
Remove compiler warnings (Including some warnings from
-Wstrict-aliasing)
Don't use static link by default (in compile-pentium) as some new
systems doesn't have all static libraries available
Change type for functions in plugin.h:str_mysql_ftparser_param() to
const unsigned char and string lengths to size_t.
One effect of the above change is that one needs to include
mysql_global.h or define size_t before including plugin.h
This fixes a case where mysql_client_test failed with newer gcc that
enables strict-aliasing by default
=== modified file 'configure.in'
--- a/configure.in2009-11-07 15:56:51 +
+++ b/configure.in2009-11-29 23:08:56 +
@@ -15,7 +15,7 @@ AC_CANONICAL_SYSTEM
# MySQL version number.
#
# Note: the following line must be parseable by win/configure.js:GetVersion()
-AM_INIT_AUTOMAKE(mysql, 5.1.39-maria-beta)
+AM_INIT_AUTOMAKE(mysql, 5.1.39-MariaDB-beta)
Ok, the package name story again...
Can you please push this to your Buildbot staging tree first
lp:~maria-captains/maria/mariadb-5.1-monty
so that we can check that this does not break the packaging scripts before
pushing into main?
Also, you should check that this does not break automatic package upgrade
(apt-get, yum) from MariaDB 5.1.38 and 5.1.39. This is not currently tested
with the Buildbot setup (we can work together to get this tested).
Naming issues are annoying ...
=== modified file 'mysql-test/t/information_schema.test'
--- a/mysql-test/t/information_schema.test2009-09-29 20:19:43 +
+++ b/mysql-test/t/information_schema.test2009-11-29 23:08:56 +
@@ -5,6 +5,9 @@
# on the presence of the log tables (which are CSV-based).
--source include/have_csv.inc
+# Check that innodb/xtradb is incompiled in as result depends on it
^^^ typo
+-- source include/have_innodb.inc
+
An alternative is to move the problematic tests to the test case
information_schema_all_engines.test, to keep some testing of
information_schema when building without innodb (this test case exists to
solve the similar problem for other engines like PBXT).
=== modified file 'mysys/lf_hash.c'
--- a/mysys/lf_hash.c 2009-01-15 21:27:36 +
+++ b/mysys/lf_hash.c 2009-11-29 23:08:56 +
@@ -124,8 +124,8 @@ retry:
we found a deleted node - be nice, help the other thread
and remove this deleted node
*/
- if (my_atomic_casptr((void **)cursor-prev,
- (void **)cursor-curr, cursor-next))
+ if (my_atomic_casptr((void **) cursor-prev,
+ (void **)(char*) cursor-curr, cursor-next))
I hope you are aware that the (char *) cast does nothing to change the
underlying violation of the strict aliasing rule? It can still be valid to do
to silence the warning of course (could add a comment that this unusual double
cast is due to GCC warnings).
The underlying violation of strict aliasing remains. The access of the memory
storing cursor-curr inside my_atomic_casptr() is done with type void *, which
is incompatible with the actual type of cursor-curr which is LF_SLIST *. So
to fix we would need to change the type of cursor-curr to void * (and would
then need additional casts between void * and LF_SLIST *). Or we could add
__attribute__(may_alias) in include/atomic/gcc_builtins.h. Or we could ignore
the problem for now ...
The same applies to all other uses of my_atomic_casptr().
=== modified file 'sql/sp_head.cc'
--- a/sql/sp_head.cc 2009-09-15 10:46:35 +
+++ b/sql/sp_head.cc 2009-11-29 23:08:56 +
@@ -1924,9 +1924,10 @@ sp_head::execute_procedure(THD *thd, Lis
if (spvar-mode == sp_param_out)
{
Item_null *null_item= new Item_null();
+Item *tmp_item= (Item*) null_item;
The cast here is not necessary, is it? (As Item is a parent class of
Item_null)
If not necessary, better remove it to avoid confusion. Or could even do just
Item *null_item= new Item_null();
=== modified file 'sql/sql_select.cc'
--- a/sql/sql_select.cc 2009-11-06 17:22:32 +
+++ b/sql/sql_select.cc 2009-11-29 23:08:56 +
@@ -3586,8 +3586,9 @@ add_key_fields(JOIN *join, KEY_FIELD **k
{
if (!field-eq(item-field))
{
+Item *tmp_item= (Item*) item;
Again, is the (Item *) cast needed? (also more places below).
=== modified file 'sql/table.cc'
--- a/sql/table.cc2009-10-15 21:38:29 +
+++ b/sql/table.cc2009-11-29 23:08:56 +
@@ -2077,8 +2077,9 @@ ulong get_form_pos(File file, uchar *hea
else
{
char *str;
+const char **tmp = (const char**) (char*) buf;
You
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (monty:2770)
Michael Widenius mo...@askmonty.org writes:
Thanks for fixing all the issues? Agree with leaving as is the couple of
things you suggested.
=== modified file 'storage/myisam/myisamlog.c'
--- a/storage/myisam/myisamlog.c2008-02-18 22:35:17 +
+++ b/storage/myisam/myisamlog.c2009-11-29 23:08:56 +
@@ -385,7 +385,7 @@ static int examine_log(char * file_name,
file_info.name=0;
file_info.show_name=0;
file_info.record=0;
- if (read_string(cache,(uchar**) file_info.name,
+ if (read_string(cache,(uchar**) (char*) file_info.name,
Kristian Better fix the real problem and not just the warning:
Kristian int err;
Kristian ...
Kristian uchar *tmp= 0;
Kristian file_info.show_name=0;
Kristian file_info.record=0;
Kristian err= read_string(cache, tmp, (uint) mi_uint2korr(head));
Kristian file_info.name= (char *)tmp;
Kristian if (err)
Kristian ...
I think my code is the same thing from all practical point of view.
In general, I think it's stupid for any compiler to assume that if you
take a pointer of an object in *any circumstances* for a function call
that the object may not change (strict-alias or not). The little
benefit you *may* get for this particular optimization (in the
function call case) is not worth it (or the discussion around it).
What happens inside GCC is this:
GCC sees a store through a uchar ** inside read_string (so the lvalue is of
type uchar *).
Later it sees a load through a char ** when file_info.show_name is read (so
the lvalue here is of type char *).
Whenever there is a load, GCC needs to decide which pending stores it has that
it needs to flush from registers to memory to be sure that the correct value
is loaded.
With -fstrict-aliasing, it will decide that it does _not_ need to flush the
store from read_string, as the lvalue types are incompatible! This is where
incorrect code may be generated.
Of course, it may decide to flush the store for other reasons (out of
registers, call of or return from a function, etc.), which is why in many
cases we see no problem.
So the difference in my suggestion is that the store in read_string() is the
same lvalue type as what is read (uchar *), so GCC will be guaranteed to force
the store before the load.
So any casting of pointers, function calls, etc. do not enter into the picture
from the point of view of GCC, as they are probably already eliminated by
other optimisations when/if the issue arises...
(It's up to you which version you prefer, just wanted to explain the issue.)
Could you check if adding the attribute to gcc_builtins.h would help ?
Even if I (and Serg) think the code is 100% safe, it can only be
better if we give the compiler more information.
I don't think it will fix the warning (the extra (char **) cast is fine for
that).
I will check if the __attribute__(may_alias) works.
In this particular case I think it's safe to ignore the problem even
if the above attribute isn't done or doesn't help.
Probably, especially as the pointer is marked volatile; strict aliasing means
the compiler _may_ theoretically generate the wrong code, not that it
necessarily will ever actually do so.
Kristian An alternative is to move the problematic tests to the test case
Kristian information_schema_all_engines.test, to keep some testing of
Kristian information_schema when building without innodb (this test case
exists to
Kristian solve the similar problem for other engines like PBXT).
Agree, but better to leave this to another patch.
We have to do a lot of work in the future to split the test suite to
two parts, one for all engines and engine specific tests.
Sounds good.
As this is done in a lot of places for my_atomic_casptr(), I don't
think a comment is needed (we can't have comment in every place).
Ok.
Kristian To fix the real problem it seems one would need to do something like
Kristian union { void *v; MARIA_USED_TABLES *m; } *prev;
Kristian which is quite ugly ...
Kristian So not sure if we should leave this (to potentially, but perhaps
unlikely,
Kristian break with new compiler), or do an ugly fix ...
This case should be 100 % safe as we are never referring to the changed
pointers in this function or any functions that could inline this function.
Yes.
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] WL40: Current status issues to discuss
Alexi1952 alexi1...@yandex.ru writes: The Query event binary format is extended with a tables info, i.e. the list of tables involved in the query execution. More precisely, two following fields are added to the Query event header: * Query length (2 bytes). (Reason: in usual format, Query event doesn't include this field because the query is considered to extent to the end of the event what is not the case for the extended format). * Tables info length (2 bytes). Length of tables info contained in the data part of the event. and the following data is added to the Query event data part: * Tables info (tables_info_len bytes). List of 4-tuples (db_len, db, table_name_len, table_name) for each table involved in the execution of the query described by this event. db_len may be zero meaning that this is the default db. This sounds somewhat dangerous. We need to consider the effect on compatibility with other servers which do not have this change. As far as I understand, MySQL replication is backwards and forwards compatible. This means that an old slave can replicate from a new master, and a new slave can replicate from an old master. I guess there must be some kind of limitations for this, but I remember seeing lots of code in the replication sources to handle such issues. Therefore, when proposing changes to the event format, we need a full analysis of the consequences for replicating from/to different server versions. We also need to consider replication to/from Sun MySQL, which probably means some kind of coordination with Sun replication engineers. (I'm not saying that we cannot change replication event formats, just that we need to do it really carefully). Also, don't know if this worklog is being actively worked on, just wanted to remark this to be sure it is not forgotten. Hope this helps, - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] need maria dev team help to repro a bug
Vladimir Kolesnikov vladi...@primebase.org writes: I'm working on this problem: https://bugs.launchpad.net/pbxt/+bug/489091 Unfortunately I cannot rperoduce plan diffs on the latest lp:~maria-captains/maria/5.1-merge. Is there a way to get access to any of your machines where it is reproducible. FYI: I provided Vladimir with access. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Warnings in MariaDB
Michael Widenius mo...@askmonty.org writes:
Here is some comments, suggestions of what we still to do to make the
buildbot part 'more clean:
Finally got to this after long wait ...
We get a lot of warnings of the type:
ctype-ucs2.c:206: warning: ‘s_wc’ may be used uninitialized in this
function
This are false warnings (The compiler is not smart enough to figure
this out). The variables are also protected with the LINT_INIT() macro.
Suggestion (for Kristian):
- If you compile with -Wuninitialized, also use the -DFORCE_INIT_OF_VARS
I added this to Buildbot, should happen for new builds.
To facilitate this, I added the feature to set extra flags and options when
using BUILD/compile-xxx scripts. For example:
BUILD/compile-pentium64-valgrind-max --extra-flags=-Wno-uninitialized -O3
New options are:
--extra-cflags# Added to CFLAGS
--extra-cxxflags # Added to CXXFLAGS
--extra-flags # Added to both CFLAGS and CXXFLAGS
--extra-configs # Added to ./configure line
The same can be achieved using environment variables:
EXTRA_CFLAGS
EXTRA_CXXFLAGS
EXTRA_FLAGS
EXTRA_CONFIGS
I use the environment variables in Buildbot instead of the options, as
Buildbot works on lots of branches, some of which do not support the new
options. Using environment variables avoid getting a build failure in these
branches or having to do extra configuration to do different kinds of build
depending on exactly what is in the branch.
When compiling for valgrind, we should not use
-Wuninitialized or -DFORCE_INIT_OF_VARS
This is already the case.
In Buildbot, I changed the Valgrind builds to compile with optimisations (as
we want to catch any problems due to compiler bugs or wrong use of C/C++ that
only shows in this case). But I kept the BUILD/compile-*-valgrind-* scripts
using no optimisation by default for easier debugging for developers.
Also, I did not change the default behaviour of BUILD/compile-pentium-max (and
similar scripts) to use -DFORCE_INIT_OF_VARS by default, as I was not sure it
is proper to have this option in build a build script that does a release
type build.
I don't know if the following warning comes from us or from the
include files:
/usr/include/bits/string3.h:82: warning: call to ‘__warn_memset_zero_len’
declared with attribute warning: memset used with constant zero length
parameter; this could be due to transposed parameters
Need suggestions/help to solve this one.
Either we need to find the code in MariaDB that generates the warning
or disable warnings in buildbot from /usr/include
This comes from YaSSL. It has this code
class Source { ...
explicit Source(word32 sz = 0) : buffer_(sz), current_(0) {}
Calling the constructor with no arguments
Source cert;
eventually ends up in this code
memset(buffer_, 0, sz_ * sizeof(T));
where sz_ is zero. So this translates into memset(buffer_, 0, 0), which glibc
has a warnings for when the last parameter is a _constant_ zero. So the
inlining is causing it here.
There are a couple ways to fix it, the simplest is probably just to add
if (sz_ != 0)
just before the memset. I have pushed this into lp:maria.
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Crash during shutdown (need help from PBXT team)
Vladimir Kolesnikov vladi...@primebase.org writes:
Unfortunately I cannot repeat the problem on my machine. Can you
please put the branch to the debian box that you gave earlier access
to?
Yes.
There is now a build directory on the box:
/home/buildbot/shutdown-crash/mysql-5.1.41-MariaDB-beta/
(I pushed the corresponding bzr version to
lp:~knielsen/maria/maria-pbxt-shutdown-crash. This is a merge of PBXT into
MariaDB).
I built using
BUILD/compile-pentium-max
I get the test failure repeatably with this:
(cd mysql-test perl mysql-test-run.pl mysqld_option_err)
It does not seem to fail the same way every time, but it does seem to fail
everytime I run it.
Let me know if you need anything else.
Thanks again for looking into this!
- Kristian.
Kristian Nielsen wrote:
[I Cc'ed Paul, let me know if there is another prefered way of communicating,
like using Launchpad bugs or some mailing list]
Vladimir Kolesnikov vladi...@primebase.org writes:
Crash during shutdown (need help from PBXT team)
can you provide any details?
Yes, of course! Just been busy with other stuff, but very happy that you
mention it on your own initiative!
Basically, after merging PBXT I see crashes in the main.mysqld_option_err
test
case. Here is an example build from Buildbot showing this:
http://askmonty.org/buildbot/builders/debian5-i386-fulltest/builds/52
http://askmonty.org/buildbot/builders/debian5-i386-fulltest/builds/52/steps/test_4/logs/stdio
The failure appears to be somewhat random, but I was able to repeat it easily
enough locally using a release build. Debug build did not seem to show the
problem.
The issue is with the fix that Paul pushed for Bug#489088:
https://bugs.launchpad.net/pbxt/+bug/489088
=== modified file 'storage/pbxt/src/myxt_xt.cc'
--- storage/pbxt/src/myxt_xt.cc 2009-11-27 15:37:02 +
+++ storage/pbxt/src/myxt_xt.cc 2009-12-01 09:50:46 +
@@ -3041,6 +3041,14 @@ xtPublic MX_CHARSET_INFO *myxt_getcharse
return (MX_CHARSET_INFO *)my_charset_utf8_general_ci;
}
+#ifdef DBUG_OFF
+//typedef struct st_plugin_int *plugin_ref;
+#define REF_MYSQL_PLUGIN(x) (x)
+#else
+//typedef struct st_plugin_int **plugin_ref;
+#define REF_MYSQL_PLUGIN(x) (*(x))
+#endif
+
xtPublic void *myxt_create_thread()
{
#ifdef DRIZZLED
+LEX_STRING plugin_name =
REF_MYSQL_PLUGIN(new_thd-variables.table_plugin)-name;
+if ((plugin_name.length == 4) (strncmp(plugin_name.str, PBXT,
plugin_name.length) == 0)) {
+REF_MYSQL_PLUGIN(new_thd-variables.table_plugin)-ref_count--;
+}
new_thd-thread_stack = (char *) new_thd;
new_thd-store_globals();
lex_start(new_thd);
This code crashes because new_thd-variables.table_plugin is NULL at this
point in the code (or at least sometimes is).
So this problem is similar to the previous problem handled just above in the
code with global_system_variables.table_plugin being NULL.
I tried a patch like this:
=== modified file 'storage/pbxt/src/myxt_xt.cc'
--- storage/pbxt/src/myxt_xt.cc 2009-12-01 09:50:46 +
+++ storage/pbxt/src/myxt_xt.cc 2009-12-04 21:41:25 +
@@ -3112,10 +3112,15 @@ xtPublic void *myxt_create_thread()
* references to the PBXT plugin object and will effectively
deadlock the plugin so* that server will have to force
plugin shutdown. To avoid deadlocking and forced shutdown * we
must dereference the plugin after creating THD objects.
+ * Similarly to global_system_variables.table_plugin as described above,
+ * new_thd-valriables.table_plugin can also become NULL due to
shutdown.
*/
-LEX_STRING plugin_name =
REF_MYSQL_PLUGIN(new_thd-variables.table_plugin)-name;
-if ((plugin_name.length == 4) (strncmp(plugin_name.str, PBXT,
plugin_name.length) == 0)) {
-REF_MYSQL_PLUGIN(new_thd-variables.table_plugin)-ref_count--;
+plugin_ref table_plugin = new_thd-variables.table_plugin;
+if (table_plugin) {
+LEX_STRING plugin_name = REF_MYSQL_PLUGIN(table_plugin)-name;
+if ((plugin_name.length == 4) (strncmp(plugin_name.str,
PBXT, plugin_name.length) == 0)) {
+REF_MYSQL_PLUGIN(table_plugin)-ref_count--;
+}
}
new_thd-thread_stack = (char *) new_thd;
new_thd-store_globals();
So this fixes the crashes, but of course re-introduces the original problem
in
Bug#489088 with warnings about forced shutdown.
I think you should be able to repeat the problem easily enough on Linux with
a
non-debug build running the test main.mysqld_option_err, but if not let me
know and I will help set something up.
- Kristian.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https
Re: [Maria-developers] Drupal - MariaDB instead of MySQL
Prashant Shah pshah.mum...@gmail.com writes: Recently setup a Drupal staging server with MariaDB and it looks good. Everything went perfectly well, and no code changes were required. Thank you for taking the time to report this, it is very useful for us to also get feedback from when things work! Keep up the good work :) Thanks :-) - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2785)
Arjen Lentz ar...@openquery.com writes: Which other external libraries are currently still embedded into the source tree? These are the ones I know of: zlib libedit libreadline yassl libevent I think most (all?) of them have a ./configure option to use the system one instead of the bundled one. I guess the main problem with boost is the sheer size. The largest of the above is yassl, with 182 files and 2 MB total size. - Kristian ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr repository
Hakan Kuecuekyilmaz ha...@askmonty.org writes: I would like to put the scripts to a bzr repository. I guess launchpad is a good place. A separate repository makes sense to me, or maybe add them to the MariaDB sources? Yes. I have for some time known we need a public repository with the tools we use for MariaDB development. So now I have created a project for this on Launchpad. Branch to push to: lp:mariadb-tools Project page: https://launchpad.net/mariadb-tools Wiki page: http://askmonty.org/wiki/index.php/Tools_for_MariaDB Everybody, please help by moving things from our internal bzr repo hasky:/usr/local/bzr into this project where relevant. And also please help by updating the wiki page with appropriate documentation. I have a first working version of the wrapper scripts to automatically run sql-bench with a set of different configurations. From this description, it sounds like something that would make sense to include in the MariaDB source tree? If so, I guess just commit them and get a review. Generally, it is an advantage to keep tools that work on a specific version of MariaDB inside the source tree, especially for automation (like Buildbot). Eg. if different variants of the scripts are needed for different MariaDB versions (maybe using a feature that is not present in older versions); keeping the scripts inside the tree trivially ensures that the versions of scripts and of MariaDB matches. It also removes any issues wiht making sure the scripts are available on a given host. On the other hand, if the script needs to work with different versions of MariaDB it probably makes sense to keep it outside of the main source tree. Maybe the script needs to check out the MariaDB source tree (like package scripts); it cannot easily checkout itself... Or maybe it needs to compare two different versions of MariaDB against each other (benchmarks, upgrade testing). For some tools the correct approach would be that part is inside the source tree and part outside. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Merge] lp:~paul-mccullagh/maria/maria-pbxt-rc3 into lp:maria
Hi Daniel, I have merged this from Paul into MariaDB. This means that the next MariaDB release (5.1.41) will include PBXT version 1.0.09f RC3 as described by Paul below. I hope you can use this to prepare MariaDB 5.1.41 release notes. - Kristian. Paul McCullagh paul.mccull...@primebase.org writes: Paul McCullagh has proposed merging lp:~paul-mccullagh/maria/maria-pbxt-rc3 into lp:maria. Requested reviews: Maria-captains (maria-captains) Related bugs: #345524 pbxt does not compile on 64 bit windows https://bugs.launchpad.net/bugs/345524 This is the 3rd RC release of PBXT. It includes a number of bug fixes (some specifically for MariaDB), and 2 features: - XA/2-Phase commit support - Online backup native driver for PBXT The backup uses the MySQL backup API (MySQL 6.0/5.4), and is not yet available in MariaDB. Release notes since the RC2 version already in MariaDB are as follows: --- 1.0.09f RC3 - 2009-11-30 RN291: Fixed bug #489088: On shutdown MySQL reports: [Warning] Plugin 'PBXT' will be forced to shutdown. RN290: Fixed bug #345524: pbxt does not compile on 64 bit windows. Currently atomic operations are not supported on this platform. RN286: Fixed a bug introduced in RN281, which could cause an index scan to hang. The original change was to prevent a warning in Valgrind. RN285: Merged changes required to compile with Drizzle. RN284: Fixed bug that cause the error [ERROR] Invalid (old?) table or database name 'mysqld.1', when running temp_table.test under MariaDB (thanks to Monty for his initial bug fix). Added a fix for partition table names as well. RN283: Added win_inttypes.h to the distribution. This file is only required for the Windows build. RN282: Fixed bug #451101: jump or move depends on uninitialised value in myxt_get_key_length RN281: Fixed bug #451080: Uninitialised memory write in XTDatabaseLog::xlog_append RN280: Fixed bug #451085: jump or move depends on uninitialised value in my_type_to_string RN279: Fixed bug #441000: xtstat crashes with segmentation fault on startup if max_pbxt_threads exceeded. --- 1.0.09e RC3 - 2009-11-20 RN278: Fixed compile error with MySQL 5.1.41. --- 1.0.09d RC3 - 2009-09-30 RN277: Added r/o flag to pbxt_max_threads server variable (this fix is related to bug #430637) RN276: Added test case for replication on tables w/o PKs (see bug #430716) RN275: Fixed bug #430600: 'Failed to read auto-increment value from storage engine' error. RN274: Fixed bug #431240: This report is public edit xtstat fails if no PBXT table has been created. xtstat now accepts --database=information_schema or --database=pbxt. Depending on this setting PBXT will either use the information_schema.pbxt_statistics or the pbxt.statistics table. If information_schema is used, then the statistics are displayed even when no PBXT table exists. Recovery activity is also displayed, unless pbxt_support_xa=1, in which case MySQL will wait for PBXT recovery to complete before allowing connections. RN273: Fixed bug #430633: XA_RBDEADLOCK is not returned on XA END after the transacting ended with a deadlock. RN272: Fixed bug #430596: Backup/restore does not work well even on a basic PBXT table with auto-increment. --- 1.0.09c RC3 - 2009-09-16 RN271: Windows build update: now you can simply put the pbxt directory under mysql-root/storage and build the PBXT engine as a part of the source tree. The engine will be linked statically. Be sure to specify the WITH_PBXT_STORAGE_ENGINE option when running win\configure.js RN270: Correctly disabled PBMS so that this version now compiles under Windows. If PBMS_ENABLED is defined, PBXT will not compile under Windows becaause of a getpid() call in pbms.h. --- 1.0.09 RC3 - 2009-09-09 RN269: Implemented online backup. A native online backup driver now performs BACKUP and RESTORE DATABASE operations for PBXT. NOTE: This feature is only supported by MySQL 6.0.9 or later. RN268: Implemented XA support. PBXT now supports all XA related MySQL statements. The variable pbxt_support_xa determines if XA support is enabled. Note: due to MySQL bug #47134, enabling XA support could lead to a crash. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Updated (by Alexi): Store in binlog text of statements that caused RBR events (47)
worklog-nore...@askmonty.org writes: +Also we should notice the introduction of the BINLOG_SEND_ANNOTATE_ROWS_EVENT +flag taking into account that MySQL/Sun may also introduce a flag with the +same value to be used in the request_dump-mysql_binlog_send interface. +But this is mainly the question of merging: if a conflict concerning this +flag occur, we may simply change the BINLOG_SEND_ANNOTATE_ROWS_EVENT value +(this does not require additional changes in the code). The issue is much harder than this, as we have to support replication between master and slave of different versions. So we cannot just change the value of flags sent between master and slave, at least not without adding code to make sure such a change is both forward and backwards compatible. I still think the correct approach here is to contact MySQL developers and make sure we coordinate the allocation of flags and constants. (If MySQL should for some reason refuse to do this, we will at least have tried, and besides I see no reason they would do this if approached politely). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2785)
Adam M. Dutko dutko.a...@gmail.com writes: Arjen, Hm, the mail is to maria-developers, but here it says Arjen, so I'm not sure which build pool you have in mind ;-) Anyway, ... Do you have a matrix of distros/platforms you'd like to see added to the build pool? I have some more compute power that I might be able to add to the build pool. For the MariaDB Buildbot we need both more hosts for generic Linux builds and for more non-linux platforms. For generic Linux especially boxes with fair upload bandwidth and/or good size memory (4/8Gb) would be really useful, and could be plugged into the system immediately. We also need much better coverage of non-Linux platforms, as well as non-i386/amd64 platforms. For example Windows 32- and 64-bit. Solaris Mac OS/X However, for these platforms it is not just having the box available, it is also someone spending the time to get the host working stably and any repeatable or random failures solved. So far this spending of time has been lacking. Eg. we have actually 4 windows slaves in Buildbot, but none of them work reliably :-( - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (monty:2786)
Michael Widenius mo...@askmonty.org writes: === modified file 'mysql-test/t/ctype_utf8.test' --- a/mysql-test/t/ctype_utf8.test2009-01-26 21:19:13 + +++ b/mysql-test/t/ctype_utf8.test2009-12-27 13:54:41 + @@ -2,6 +2,15 @@ # Tests with the utf8 character set # +let collation=utf8_unicode_ci; +--source include/have_collation.inc + +--disable_warnings +drop table if exists t1,t2,t3,t4; +drop database if exists mysqltest; +--enable_warnings + + There is no matching update of the ctype_utf8.result file (or alternatively --disable_query_log)! So this will cause the test suite to fail. (Ah, I see you already pushed this, and indeed the test fails in Buildbot on all hosts now). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 2PC between two engines + binlog
Paul McCullagh paul.mccull...@primebase.org writes: All tests look good, so I have proposed the bug fix mentioned below for merging: lp:~paul-mccullagh/maria/maria-pbxt-1009g Thanks! I have merged this into the MariaDB 5.1.41 release clone (will later also be merged into main lp:maria). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Rev 4: Added wrapper scripts for automated runs of sql-bench
Sergei Golubchik ser...@pisem.net writes: On Dec 29, Hakan Kuecuekyilmaz wrote: +# Note: Do not run this script with root privileges. +# We use killall -9, which can cause severe side effects! You can use killall -u `whoami` not perfect, but still much safer. There is another, robust way to do this: Make the parent process a group leader with setpgid(0,0). Then `kill -9 -$$` will kill only the processes started from that parent (or from children, recursively). Or use setsid to create a session leader for even more robust killing (there is a setsid command available to do this within shell scripts). (You might not need this for your purpose, but I thought I would mention it in case you at some point may want to run this in Buildbot or similar). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (monty:2787)
Michael Widenius mo...@askmonty.org writes: #At lp:maria based on revid:kniel...@knielsen-hq.org-20100105142834-adpbyr6x7edubwps 2787 Michael Widenius2010-01-06 Removed compiler warnings This push broke Windows compilation, see below. OpenSolaris 5.11-x86 now compiles (tested with 32 bit) It still fails in Buildbot. I am not 100% sure, but I think this is because it fails in 64-bit. When I looked, I found that there is a check in ./configure to see if we can use assembler, and then later assembler is used if the configure check was ok. But there was some difference in CFLAGS or the like between the test and the use. So I suppose the test is using 32-bit mode (which works) but the use is using 64-bit mode (which fails). [Not 100% sure about this and also don't know how to fix ...] === modified file 'extra/libevent/devpoll.c' --- a/extra/libevent/devpoll.c2009-03-12 22:27:35 + +++ b/extra/libevent/devpoll.c2010-01-06 21:27:53 + @@ -185,7 +185,9 @@ devpoll_init(struct event_base *base) } static int -devpoll_recalc(struct event_base *base, void *arg, int max) +devpoll_recalc(struct event_base *base __attribute__((unused)), + void *arg __attribute__((unused)), + int max) Unfortunately, we cannot do this. __attribute__((unused)) is a GCC extension. Now that this is pushed to 5.1-release, compilation fails on Windows: Building C object extra/libevent/CMakeFiles/libevent.dir/evbuffer.c.obj evbuffer.c extra\libevent\evbuffer.c(79) : error C2146: syntax error : missing ')' before identifier '__attribute__' extra\libevent\evbuffer.c(79) : error C2061: syntax error : identifier '__attribute__' extra\libevent\evbuffer.c(79) : error C2059: syntax error : ';' extra\libevent\evbuffer.c(79) : error C2182: 'unused' : illegal use of type 'void' extra\libevent\evbuffer.c(79) : error C2059: syntax error : 'type' extra\libevent\evbuffer.c(80) : error C2059: syntax error : ')' === modified file 'extra/libevent/evbuffer.c' --- a/extra/libevent/evbuffer.c 2009-03-12 22:27:35 + +++ b/extra/libevent/evbuffer.c 2010-01-06 21:27:53 + @@ -75,7 +75,8 @@ bufferevent_add(struct event *ev, int ti */ void -bufferevent_read_pressure_cb(struct evbuffer *buf, size_t old, size_t now, +bufferevent_read_pressure_cb(struct evbuffer *buf, + size_t old __attribute__((unused)), size_t now, Again __attribute__ breaks Windows build. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (monty:2787)
Kristian Nielsen kniel...@knielsen-hq.org writes: Michael Widenius mo...@askmonty.org writes: #At lp:maria based on revid:kniel...@knielsen-hq.org-20100105142834-adpbyr6x7edubwps 2787 Michael Widenius 2010-01-06 Removed compiler warnings This push broke Windows compilation, see below. For now, I pushed to 5.1-release a revert of this part of the patch (the __attribute__ additions inside libevent) to get Windows building again. Hopefully you can find a better way to remove the warnings. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Status of Windows build
[moving the discussion to maria-develop...@] Timour Katchaounov tim...@askmonty.org writes: Sergey, 1. buy VS Enterprise Edition (or Standard Edition, I wasn't able to figure out what exactly do we need to make builds. They don't offer evaluation versions of Standard, only Enterprise). 2. make the build script support building with VS Community Edition (possible but will take some time). No, we should not build with VS Community Edition. AFAIK, the free edition's compiler produces much less optimized code than the payed for editions. I don't think it is serious on our side to save money by not buying one VS license. On the other hand, the advantage of building with the community edition (I think we really mean the express / no-cost edition right?) is that it makes it easier for people to build themselves (and get the same result as our release builds). This is IMO important, we are an Open Source project after all. So it would be interesting to learn if there really is a speed difference here. Do you have some background information on this? Or do we need to run benchmarks to know for sure? One more alternative would be to create a Windows virtual machine, and install the evaluation version in the VM. Then once there is a copy, one can always roll-back to the fresh installation. Given what is at stake, I'd much prefer that we have a license of VS. As I said above, I would prefer using the no-cost version, unless there is a real reason not to. Just my 2 cents, - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Status of Windows build
Timour Katchaounov tim...@askmonty.org writes: - Making it possible for any developer to build (and develop) MariaDB on Windows with Visual C++. This is perfectly possible with either edition of Visual C++. I want it to be easy for people to build themselves something that is as good as what we release. At MySQL, there were tons of magic in secret build scripts used to build releases, and I desparately want to avoid that. (I'm not saying that we are doing the same for Windows currently, just explaining my reasoning). Thus all else being equal I want us to spend our efforts primarily on building with the tools that our users (those that want to build themselves) will be building with. (But as you explain below, all else is not equal). I spent half an hour searching MS web site for a comparison of the versions, and Bo seems right - no differences are claimed with respect to the optimizing compiler. The major two differences I found in the VC++ 2008 that affect us are: A) The Express Edition cannot build 64-bit binaries. Right, that's a showstopper :-/ - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Patch for Windows problem with setting TZ
Hi,
Alex Budovski has done some work to debug why some tests (binlog tests in
particular) are failing on Windows, and found that this is because
mysql-test-run.pl set the TZ variable. This interacts poorly with the Windows
Operating System.
It's actually only a few test cases that need to set TZ. Here is a quick patch
that avoids the need to set TZ except for tests that specifically requests it
(with the already existing --timezone=XXX mechanism in -master.opt).
Opinions?
- Kristian.
=== modified file 'mysql-test/include/ps_conv.inc'
--- mysql-test/include/ps_conv.inc 2007-07-04 09:20:53 +
+++ mysql-test/include/ps_conv.inc 2010-01-16 11:40:42 +
@@ -30,6 +30,9 @@
--disable_warnings
drop table if exists t5 ;
--enable_warnings
+--disable_query_log
+SET TIME_ZONE= '+03:00';
+--enable_query_log
set @arg01= 8;
set @arg02= 8.0;
set @arg03= 80.000e-1;
=== modified file 'mysql-test/mysql-test-run.pl'
--- mysql-test/mysql-test-run.pl 2010-01-06 21:27:53 +
+++ mysql-test/mysql-test-run.pl 2010-01-16 11:53:58 +
@@ -3425,7 +3425,7 @@ sub restart_forced_by_test
# Return timezone value of tinfo or default value
sub timezone {
my ($tinfo)= @_;
- return $tinfo-{timezone} || GMT-3;
+ return $tinfo-{timezone} || DEFAULT;
}
@@ -3455,7 +3455,9 @@ sub run_testcase ($$) {
# Init variables that can change between each test case
# ---
my $timezone= timezone($tinfo);
- $ENV{'TZ'}= $timezone;
+ if ($timezone ne 'DEFAULT') {
+$ENV{'TZ'}= $timezone;
+ }
mtr_verbose(Setting timezone: $timezone);
if ( ! using_extern() )
=== modified file 'mysql-test/suite/binlog/r/binlog_unsafe.result'
--- mysql-test/suite/binlog/r/binlog_unsafe.result 2010-01-15 15:27:55 +
+++ mysql-test/suite/binlog/r/binlog_unsafe.result 2010-01-16 11:36:09 +
@@ -380,6 +380,7 @@ INSERT INTO t1 VALUES (VERSION());
Warnings:
Note 1592 Statement may not be safe to log in statement format.
DELETE FROM t1;
+SET TIME_ZONE= '+03:00';
SET TIMESTAMP=100;
INSERT INTO t1 VALUES
(CURDATE()),
=== modified file 'mysql-test/suite/binlog/t/binlog_unsafe.test'
--- mysql-test/suite/binlog/t/binlog_unsafe.test 2010-01-15 15:27:55 +
+++ mysql-test/suite/binlog/t/binlog_unsafe.test 2010-01-16 11:35:52 +
@@ -422,6 +422,7 @@ DELETE FROM t1;
# following following functions depend on the TIMESTAMP variable and
# don't generate a warning.
+SET TIME_ZONE= '+03:00';
SET TIMESTAMP=100;
INSERT INTO t1 VALUES
(CURDATE()),
=== modified file 'mysql-test/suite/rpl/r/rpl_mixed_ddl_dml.result'
--- mysql-test/suite/rpl/r/rpl_mixed_ddl_dml.result 2008-11-04 17:07:14 +
+++ mysql-test/suite/rpl/r/rpl_mixed_ddl_dml.result 2010-01-16 11:33:22 +
@@ -18,6 +18,7 @@ Server_id Host Port Rpl_recovery_rank Ma
drop table t1;
stop slave;
create table t2(id int auto_increment primary key, created datetime);
+SET TIME_ZONE= '+03:00';
set timestamp=12345;
insert into t2 set created=now();
select * from t2;
=== modified file 'mysql-test/suite/rpl/t/rpl_mixed_ddl_dml.test'
--- mysql-test/suite/rpl/t/rpl_mixed_ddl_dml.test 2007-06-27 12:28:02 +
+++ mysql-test/suite/rpl/t/rpl_mixed_ddl_dml.test 2010-01-16 11:32:56 +
@@ -23,6 +23,7 @@ connection master;
# Test replication of timestamp
create table t2(id int auto_increment primary key, created datetime);
+SET TIME_ZONE= '+03:00';
set timestamp=12345;
insert into t2 set created=now();
select * from t2;
=== added file 'mysql-test/t/mysqlbinlog2-master.opt'
--- mysql-test/t/mysqlbinlog2-master.opt 1970-01-01 00:00:00 +
+++ mysql-test/t/mysqlbinlog2-master.opt 2010-01-16 12:00:07 +
@@ -0,0 +1 @@
+--timezone=GMT-3
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Patch for Windows problem with setting TZ
Kristian Nielsen kniel...@knielsen-hq.org writes: Why we didn't have this problem with MySQL in pushbuild ? Yeah, that's what I asked myself as well? Or maybe it shows only on some Windows systems. I remember Igor and Sergey saw binlog test failures on one Windows system and not on another. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Patch for Windows problem with setting TZ
Sergei Golubchik ser...@pisem.net writes: On Jan 16, Kristian Nielsen wrote: It's actually only a few test cases that need to set TZ. Here is a quick patch that avoids the need to set TZ except for tests that specifically requests it (with the already existing --timezone=XXX mechanism in -master.opt). Why we didn't have this problem with MySQL in pushbuild ? With the help of Alex Budovski I think I now have the answer: The binlog failures happen because when the TZ variable is changed to +03:00 on boxes with USA time zone (or similar), PURGE BEFORE DATE statements picks up the wrong files, apparently TZ only affects some parts of the system (localtime()), not others (file dates). But on boxes with European times zones, that particular TZ change happens to not affect those statements... And in fact Igor in USA previously got binlog failures while boxes in Buildbot and at MySQL without the failures were in European time zones... I will push my fix after full tests. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Ideas for improving MariaDB/MySQL replication
The three companies Continuent, Codership, and Monty Program are planning to start working on some enhancements to the replication system in MariaDB, together with anyone interested in joining in. At this stage, there are no fixed directions for the project, and to do this in as open a way possible with the maximum community involvement and interest, we agreed to start with an email discussion on the maria-developers@ mailing list. So consider it started! The plan so far is: 1) The parties taking this initiative, MP, Continuent, and Codership, present their own ideas in this thread on maria-developers@ (and everyone else who wants to chime in at this stage). 2) Once we have some concrete suggestions as a starting point, we use this to reach out in a broader way with some blog posts on planetmysql / planetmariadb to encourage further input and discussions for possible directions of the project. Eventually we want to end up with a list of the most important goals and a possible roadmap for replication enhancements. (It is best to have something concrete as a basis of a broad community discussion/process). To start of, here are some points of interest that I collected. Everyone please chime in with your own additional points, as well as comments and further details on these one. Three areas in particular seem to be of high interest in the community currently (not excluding any other areas): - High Availability * Most seems to focus on building HA solutions on top of MySQL replication, eg. MMM and Tungsten. * For this project, seems mainly to be to implement improvements to replication that help facilitate improving these on-top HA solutions. * Tools to automate (or help automate) failover from a master. * Better facilities to do initial setup of new slave without downtime, or re-sync of an old master or slave that has been outside of the replication topology for some period of time. - Performance, especially scalability * Multi-threaded slave SQL thread. * Store the binlog inside a transactional engine (eg. InnoDB) to reduce I/O, solve problems like group commit, and simplify crash recovery. - More pluggable replication * Make the replication code and APIs be more suitable for people to build extra functionality into or on top of the stock MySQL replication. * Better documentation of C++ APIs and binlog format. * Adding extra information to binlog that can be useful for non-standard replication stuff. For example column names (for RBR), checksums. * Refactoring the server code to be more modular with APIs more suitable for external usage. * Add support for replication plugins, types to be determined. For example binlog filtering plugins? It is also very important to consider the work that the replication team at MySQL is doing (and has done). I found a good deal of interesting information about this here: http://forge.mysql.com/wiki/MySQL_Replication:_Walk-through_of_the_new_5.1_and_6.0_features) This describes a number of 6.0/5.4 and preview features that we could merge and/or contribute to. Here are the highlights that I found: - Features included in 6.0/5.4 (which are cancelled I think, but presumably this will go in a milestone release): * CHANGE MASTER ... IGNORE_SERVER_IDS for better support of circular replication. * Replication heartbeat. * sync_relay_log_info, sync_master_info, sync_relay_log, relay_log_recovery for crash recovery on slave. * Binlog Performance Optimization (lock contention improvement). * Semi-synchronous Replication, with Pluggable Replication Architecture. http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication - Feature previews: * Parallel slave application: WL#4648 http://forge.mysql.com/wiki/ReplicationFeatures/ParallelSlave * Time-delayed replication: WL#344 http://forge.mysql.com/wiki/ReplicationFeatures/DelayedReplication * Scriptable Replication: WL#4008 http://forge.mysql.com/wiki/ReplicationFeatures/ScriptableReplication * Synchronous Replication. Drizzle is also doing work on a new replication system. I read through the series of blog posts that Jay Pipes wrote on this subject. They mostly deal with how this is designed in terms of the Drizzle server code, and is low on detail about how the replication will actually work (the only thing I could really extract was that it is a form of row-based replication). If someone has links to information about this that I missed, it could be interesting. Let the discussion begin! - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Ideas for improving MariaDB/MySQL replication
Alex Yurchenko alexey.yurche...@codership.com writes: So when refactoring replication code and API we suggest to think of replication as of redundancy service and establish a general API for such service that can be utilized by different implementations with different qualities of service. In other words - make a whole replication system a plugin (like storage engines are), not only some measly filters. Serg pointed me to this page, which is an early description of a plugin API for replication that the replication team at MySQL has implemented: http://forge.mysql.com/wiki/ReplicationFeatures/ReplicationInterface It seems this is what they used to implement Semi-Synchronous replication, which (as I mentioned) is available as a feature preview: http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication You might want to look into it. The semi-synchronous replication is in fact loaded as a plugin in the MySQL implementation; this is from the presentation: On master – INSTALL PLUGIN 'rpl_semi_sync_master' SONAME 'libsemisync_master.so'; – SET rpl_semi_sync_master_enabled=1; – SET rpl_semi_sync_master_timeout=1000; (1s, default 10ms) On slave – INSTALL PLUGIN 'rpl_semi_sync_slave' SONAME 'libsemisync_slave.so'; – SET rpl_semi_sync_slave_enabled=1; – START SLAVE; We already have a number of links now, so I created a wiki page to collect this and other information for easy access: http://askmonty.org/wiki/index.php/ReplicationProject (Let me know if you need edit rights on this page; we haven't fully sorted out how to handle community access to edit on the wiki, but we will add it somehow if necessary). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] BuildBot Status Checker
Adam M. Dutko dutko.a...@gmail.com writes: I realized my buildbots went offline earlier today but wasn't notified when they did. I've worked to rectify that situation by writing a small PHP script. The lastest commit is at Unfortunately, I have not had time to look into this yet :-/. Just wanted to let you know I haven't forgotten! I wanted to have this set up in our monitoring system for the buildbot slaves that we manage, so we get an alarm in case of problems. I still hope to get to it eventually. Unless Daniel beats me to it ;-) (Cc:ed). Thanks, - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Patch for Windows problem with setting TZ
Kristian Nielsen kniel...@knielsen-hq.org writes: The binlog failures happen because when the TZ variable is changed to +03:00 on boxes with USA time zone (or similar), PURGE BEFORE DATE statements picks up the wrong files, apparently TZ only affects some parts of the system (localtime()), not others (file dates). But on boxes with European times zones, that particular TZ change happens to not affect those statements... And in fact Igor in USA previously got binlog failures while boxes in Buildbot and at MySQL without the failures were in European time zones... I will push my fix after full tests. I got a lot of random test failures with this patch unfortunately. I'm speculating that this is somehow related to settings from one test affecting another now that TZ is no longer set before every test. I need to investigate more though. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Fix for 2 failing tests on Windows
Alex Budovski abudov...@gmail.com writes: Some tests that call mtr.add_suppression to ignore expected warnings hard-code the forward slash '/' character as the expected path delimiter. This breaks tests on Windows as the regex does not match as expected. E.g. Recovering table: './mysqltest/t_corrupted2' fails to match 100123 23:48:26 [Warning] Recovering table: '.\mysqltest\t_corrupted2' and hence the test fails spuriously. Attached is a simple patch that fixes this issue while maintaining compatibility with other platforms. Let me know what you think. Good catch, thanks! I will incorporate this together with the binlog test fixes when I solve the problem with test failures. Is there any special reason you added --disable_query_log around the suppression calls, or was it just to avoid having to edit the .result? (Just curious, agree that there is little use in having them in .result in the first place). - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Branch ~maria-captains/maria/5.1] Rev 2809: Support building with system libevent
nore...@launchpad.net writes: revno: 2809 committer: Sergei Golubchik ser...@pisem.net branch nick: maria-5.1 timestamp: Fri 2010-01-29 21:35:56 +0100 message: Support building with system libevent modified: config/ac-macros/libevent.m4 Thanks! Unfortunately, I was a bit too optimistic about using system libevent. It turns out that the thread scheduler code needs libevent 1.4, but lots of our build systems have only libevent 1.3 in their distros. So we get build failures like this when libevent-dev 1.3 is installed: scheduler.cc: In function ‘bool init_socketpair(int*)’: scheduler.cc:146: error: ‘evutil_socketpair’ was not declared in this scope scheduler.cc:147: error: ‘evutil_make_socket_nonblocking’ was not declared in this scope scheduler.cc: In function ‘void close_socketpair(int*)’: scheduler.cc:154: error: ‘EVUTIL_CLOSESOCKET’ was not declared in this scope scheduler.cc:156: error: ‘EVUTIL_CLOSESOCKET’ was not declared in this scope I guess the solution is to check for system libevent version also, and if too old treat it the same way as not present. Seems we can check for the presense of the evutil_socketpair() function, which was added in libevent 1.4. Then I also need to decide what to do for packages when system libevent is too old. I checked, and Debian 4+5 and Ubuntu up to 9.04 have only libevent 1.3. Ubuntu = 9.10 has libevent 1.4. I think the best is to use bundled libevent on those older distros. We will then still suffer from https://bugs.launchpad.net/maria/+bug/509521 on those, but hopefully most people using plugins which require libevent will build mariadb themselves and/or use a newer distro. Alternatively, we can disable pool-of-threads on those older distros. (A different alternative would be to see if we can modify the pool-of-threads code to work with libevent 1.3. Not too keen to spend time on this though.) Opinions? - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Branch ~maria-captains/maria/5.1] Rev 2809: Support building with system libevent
Kristian Nielsen kniel...@knielsen-hq.org writes: I guess the solution is to check for system libevent version also, and if too old treat it the same way as not present. Seems we can check for the presense of the evutil_socketpair() function, which was added in libevent 1.4. Looks like something like this works: === modified file 'config/ac-macros/libevent.m4' --- config/ac-macros/libevent.m42010-01-29 20:35:56 + +++ config/ac-macros/libevent.m42010-01-30 11:53:39 + @@ -54,7 +54,7 @@ AC_DEFUN([MYSQL_CHECK_LIBEVENT], [ | yes) libevent_includes= libevent_libs=-levent - AC_CHECK_LIB(event, event_get_version,[with_libevent=system], + AC_CHECK_LIB(event, evutil_socketpair,[with_libevent=system], [with_libevent=bundled]) AC_CHECK_HEADER(event.h,,[with_libevent=bundled]) if test $with_libevent = bundled; then Any objections? - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Support building with system libevent
Sergei Golubchik s...@askmonty.org writes: Surely, it is possible to install a libevent 1.4 deb on Debian = 5 and Ubuntu = 9.04, right ? They are not in the default package repository - is that a big deal ? MariaDB is not either. Possible yes, but only if one knows where to obtain such a .deb package. I don't know anywhere such a package is available for older Ubuntu/Debian? (One could try installing the package from a newer Ubuntu or Debian unstable, may or may not work. But in general in .deb world people expect to not have to manually go hunt for dependencies. Maybe .rpm is different?) MariaDB is in the default repository list if users put the OurDelta repository there, which is the recommended way to install .deb. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] We need instructions for manually installing .deb
Hi Daniel, We really need to put some instructions prominently on the download page for installing the .debs. I have seen users having big problems installing them. Just something like `dpkg --install *.deb` does not work at all :-( I actually had to spend like 15 minutes sorting out exactly how to install it, many users would have given up. Here are the commands that I found will work on Debian 5 amd64 (hopefully other .deb distros will be similar): sudo apt-get update sudo apt-get install libdbi-perl libdbd-mysql-perl psmisc sudo dpkg --install mysql-common_5.1.42-mariadb73_all.deb sudo dpkg --install libmariadbclient16_5.1.42-mariadb73_amd64.deb libmysqlclient16_5.1.42-mariadb73_amd64.deb mariadb-client_5.1.42-mariadb73_all.deb mariadb-client-5.1_5.1.42-mariadb73_amd64.deb mariadb-server_5.1.42-mariadb73_all.deb mariadb-server-5.1_5.1.42-mariadb73_amd64.deb Also, as soon as OurDelta has the 5.1.42 repositories up, we need a strong warning against manually installing the .debs, strongly suggesting the OurDelta repositories instead, as it will work much better for users. (With the repositories, just `apt-get install mariadb-server` will work, as will the Synaptic package manager GUI). I hope you will be able to sort out some instructions, else ask me and I will try to help. This is made somewhat more urgent since after FOSDEM a number of people will probably want to try out the .debs ASAP, as we advertised them ... - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
