Postgres-based murmur crashes trying to migrate to 1.3.1 #4292
Comments
|
Could you show which tables do exist after you have run 1.3.1 and it crashed? |
|
|
PS. server, not client (label is wrong) |
|
Okay so by looking at the code I think all the The actual crash coming from the foreign key constraint, seems to be triggered by this line: mumble/src/murmur/ServerDB.cpp Line 608 in 9f5aab4 Interestingly though this line hasn't changed in 6 years... Was this the first time you performed a Mumble update? Or did you use older versions (with Postgres!) before and they upgraded just fine? |
|
As far as I remember I was using 1.2.something with postgres already, or I may be wrong. The file was created on Feb 23, so I'll look up version of This time I just rebuilt the containers (as I do few times a week), package was updated so my bet was error in 1.3.1. |
|
It seems that's my first upgrade with postgres, my initial Dockerfile was already 1.3.0 based. What else can I provide to help? |
|
I built 1.3.0-r6 from alpine aports, plugged it to the same DB and.. It worked ;o |
|
It could very well be that the issue was introduced in 1.3.1. I tinkered with the DB code in order to fix the encoding, so maybe I broke something. Could you create a SQL dump of your database before upgrading that you could send to me, so that I can test this out myself? (see https://www.postgresql.org/docs/9.1/backup-dump.html) Furthermore it might also be a great help if you could experiment with removing parts of the content and check whether the crash still happens. If yes, leave the content out, if no: put it back in and delete something else. That way we should be able to narrow down what could be the root of the problem. You can put the dump into a file and send it to me via Lines 122 to 123 in 9f5aab4 (I hope you don't have gigabytes of data in your DB? ^^) |
|
I will send you whole docker stack tared, it will be easier for both of us (probably ;x ). |
|
I sent you an email with attached dump and docker stack in tarball. EDIT: Mail was rejected by gmail, but it seems not to be needed - issue is reproducible without my db. |
|
Migration of clean 1.3.0 to 1.3.1 also fails. Log of 1.3.0: Then 1.3.1: |
|
Clean install of 1.3.1 works good with postgres, just migration from older version fails. |
You didn't send it yet though, did you? If so I haven't received it 👀
That means I'm not guilty :D Okay I guess that means database migration with Postgres is broken in general. The question now is: What is the relevant entry in the database that makes the migration fail? I guess it has something to do with Postgres doing more checks in regards to inter-table-dependencies which we seem to not take into account during the migration... |
XD
Me neither! XD
How can I help you then? Could I do something? |
Did you already try upgrading an empty DB? Did that also crash? |
|
Upgrading empty db doesn't mean clean install? |
No - in that case no upgrade is performed. You'd get this by performing a clean install of an older version (let's say 1.3.0), starting it up once and then upgrading to 1.3.1 without having interacted with the server. It'll create the database on startup but as long as you don't join the server and start creating channels, etc. the DB will remain (pretty much) empty... |
|
So that's the case I tried here and it failed to migrate: #4292 (comment) |
|
Oh yeah - forgot about that. Sorry 🙈 Okay then I guess all that remains is actually debugging and fixing the code. I'm not sure yet when I'll get to it though. If you (or someone reading this) would be willing to take that on and submit a PR, we'd be very grateful :) |
…on constraints This fixes the second case of PostgreSQL migration failure in #4292 Not tested with a players table, and tested only on PostgreSQL though the changes should make the drops work better on any database. Additionally the changes were left minimal to not introduce new issues, rather than reordering the whole section to the most logical order.
This fixes the second case of PostgreSQL migration failure in mumble-voip#4292
|
I've been having the same issue. My server was initially setup on postgres (no migration). I'm currently on version 1.3.0 and haven't been able to upgrade to 1.3.1 or 1.3 2. |
|
1.3.3 didn't fix the issue: This is the latest murmur from |
|
Yes that is expected. The fix mentioned in the changelog was for another error that was encountered with PostgreSQL |
Odd it fixed the issue for me. I actually just upgraded to 1.3.3 yesterday without issue on Arch. |
|
latest pgsql12 version from docker |
|
anything? I'm still stuck on 1.3.0 |
|
Not really sure why the issue got resolved in 1.3.3 for me in Arch. Unless the Arch devs made their own changes but I doubt that.
|
|
Same for me. Jumping from 1.3.0 to 1.3.3 on Arch resolved this issue for me on PostgreSQL version 12.5. The Arch Linux murmur package is as close to upstream as it can get, no custom patches: https://github.com/archlinux/svntogit-community/tree/packages/mumble/trunk |
|
Iirc there were no database related changes in 1.3.3 though. So this version fixing this issue is a bit odd 🤔
No. I simply did not find the time yet to work on this and afaik no one else has tried it either. |
|
Have you tried upgrading from 1.3.0 to 1.3.3?
|
|
I tried c: |
|
It probably can be closed. |
|
Oh that's interesting. I didn't even know there was such a thing like a DB schema 👀 In terms of migration I could imagine that in the future (once the DB stuff has been rewritten) one coukd export/import the DB to/from JSON. That should allow for easy transitions 🤔 |
Describe the bug
My server deny to start after upgrade. I forgot to backup it C:
Steps to Reproduce
May be not that easy, but I haven't tried..
It was sqlite 1.2.X server migrated to postgres with pgloader, but it worked after this :X
Now after upgrade 1.3.0 to 1.3.1 it refuses to start.
It may be as easy as just trying to start 1.3.1 murmur on 1.3.0 data.
Expected behavior
Work?
Screenshots
The text was updated successfully, but these errors were encountered: