Update has been completed. A few months ago I foolishly updated to a beta version, and this introduced database changes that are not part of the standard migration path. So of course, the standard migration scripts that get run on startup failed, and I’m left with a broken instance.
I had two functions of the same name when the migration script was only expecting the one. So I removed the one that didn’t match the expected function body, and the migraton worked.
I also wanted to migrate pict-rs from the disk-based SLED database to its own PostGres instance, but at the rate it was going, it was going to take 4 hours. The server its running on is full NVMe, enterprise hardware (Dell Poweredge) but its getting on a bit (I’ll be purchasing a newer server for the datacenter later this year).
I shall retry the pict-rs migration in the next few days but it will mean an extended downtime.
Update has been completed. A few months ago I foolishly updated to a beta version, and this introduced database changes that are not part of the standard migration path. So of course, the standard migration scripts that get run on startup failed, and I’m left with a broken instance.
Luckily some others had the same issue and this was discussed at https://github.com/LemmyNet/lemmy/issues/4641#issuecomment-2071033771
I had two functions of the same name when the migration script was only expecting the one. So I removed the one that didn’t match the expected function body, and the migraton worked.
I also wanted to migrate pict-rs from the disk-based SLED database to its own PostGres instance, but at the rate it was going, it was going to take 4 hours. The server its running on is full NVMe, enterprise hardware (Dell Poweredge) but its getting on a bit (I’ll be purchasing a newer server for the datacenter later this year).
I shall retry the pict-rs migration in the next few days but it will mean an extended downtime.