Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Done
-
None
-
None
Description
Hey dbart,
I made a change in 10.5 that changed the way libmariadbd.a was generated using a scripted version of ar. Generally this is fine except for the kvm-deb-xenial-ppc64le worker node. On a local Power8 xenial docker image I was able to complete the build in the same way without error.
example failure: http://buildbot.askmonty.org/buildbot/builders/kvm-deb-xenial-ppc64le/builds/6836/steps/compile/logs/stdio
Can I ask for a binutils upgrade on kvm-deb-xenial-ppc64le. - 2.26.1-1ubuntu1~16.04.8 worked for me.
Secondly the minor-upgrade-* tests are failing on:
+ mysql -uroot -prootpass -e 'SELECT * FROM db.t_memory; INSERT INTO db.t_memory VALUES (1,'\''foo'\''),(2,'\''bar'\'')'
|
+----+------+
|
| a4 | c4 |
|
+----+------+
|
| 1 | foo |
|
| 2 | bar |
|
+----+------+
|
ERROR 1062 (23000) at line 1: Duplicate entry '1' for key 'a4'
|
I assume db.t_memory is meant to be a memory storage engine based on the surrounding logs however the error indicates that some data exists there already. Can you ensure it is the same table definition as other builders?
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
binutils on kvm-deb-xenial-ppc64le updated to binutils_2.26.1-1ubuntu1~16.04.8 from 2.26.1-1ubuntu1~16.04.3
It turns out the problem with the test failure with the t_memory table is with the ok-10.5-cs tree. The test is working exactly like it should.
From what I learned talking with elenst, as part of the minor-upgrade-deps test, buildbot installs the packages that were just built over the top of the latest released version of MariaDB in the same base version. In this case 10.5.3 was installed from our repositories, and then the test tries to install the packages that were just built. But the ok-10.5-cs tree (as of the commit in this test) hasn't pulled in the version bump to 10.5.4 from the main 10.5 tree so when the install test happens nothing happens (the VM already had 10.5.3 installed and the new packages from the ok-10.5-cs tree also had the 10.5.3 version number, so apt considered them to be equivalent and did nothing).
The server didn't get upgraded, so the server didn't restart, so the t_memory table didn't get wiped (which would have happened if the server had restarted), so the INSERT failed.
kvm-deb-xenial still failed after updating binutils: http://buildbot.askmonty.org/buildbot/builders/kvm-deb-xenial-ppc64le/builds/6847
Thanks for the upgrade. I'll look again to work out the underlying cause.
Thanks for the upgrade explanation. Makes sense.
MDEV-22887 was filed for the underlying cause, and I am working on it.
Are any more updates needed to the xenial-ppc64le builders? If not, I'll close this issue.
The t_memory table is created earlier in the test and when it is created some initial values are inserted, then later on new values are inserted, but unlike the other tables in the test that are being updated the same initial values are being inserted again. I think this is an error in the test, but I'll confirm with elenst before I change it.