Problem/Motivation
When updating from 8.6.x to 8.7 the following error (or similar) may occur:
[error] Exception thrown while performing a schema update. Cannot rename tmp_a207a5menu_link_content_revision to menu_link_content_revision: table menu_link_content_revision already exists.
This normally occurs when attempting to run the DB update a second time, after that a previous attempt failed with a different error.
There are a couple of people reporting that the issue happens on fresh a DB where the update was never attempted (see #77 see and #86), but the root/original error was not reported yet.
Here's a list of issues that may cause the first error:
- #3052492: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved
- #3006815: ViewsEntitySchemaSubscriber may fail when a view has a broken handler
Proposed resolution
There is no proposed solution yet, since the focus so far has been to fix the initial error(s) in dedicated issues, for instance #3052492: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved. The problem is that many different problems can result in a failed update, which on a second attempt would lead to the reported error. This issue will focus on finding a fix for bugs triggering the reported errors on the first run, while separate issues will be created to address bugs triggering the reported errors on the second run.
The current working hypothesis to explain the error occurring on the first attempt is that for some reason the update is run on a DB where the menu link content (and/or taxonomy term) entity type was already converted to revisionable, possibly via drush entup
. A patch was posted to address this issue (latest version at #83).
However in most cases it seems people are experiencing this error as a consequence of a previously failed update. The workaround in this case is to remove the revision tables created by the update (see #39), in fact just restoring a fresh DB dump may not be enough (see #29).
It is also possible that a similar error occurs with the taxonomy_term
entity type, see #81. It is very important to make sure that the update actually failed before dropping tables, otherwise this could result in a broken database, see for instance #60. In that case the menu_link_content
had likely completed successfully.
Please note that a successful update will not remove backup tables (tables prefixed by old_
) unless the system is specifically configured to do so, see https://www.drupal.org/node/3046576.
Remaining tasks
- Confirm that the error can occur also on the first run and track down the root cause.
- Write a patch
- Reviews
User interface changes
None
API changes
None
Data model changes
None
Release notes snippet
TBD
Comments
Comment #2
joelpittetComment #3
joelpittetComment #4
joelpittetThe callstack while debugging with @amateescu:
Commenting out
$view->trustData()->save();
fromcore/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php:202
Allowed these to go through!
Comment #5
plachThis might be related to #2554235: Make the content entity storage and entity query use the last installed definitions instead of the ones living in code and or #2274017: Make SqlContentEntityStorage table mapping agnostic .
Comment #6
amateescu CreditAttribution: amateescu commentedComment #7
amateescu CreditAttribution: amateescu commentedI posted a patch in #2554235-19: Make the content entity storage and entity query use the last installed definitions instead of the ones living in code which should fix this issue.
Comment #8
BrightBoldHmm. I just updated a site from 8.6.13 to 8.7-beta2 and got this error.
Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. Cannot rename tmp_9266famenu_link_content to menu_link_content: table tmp_9266famenu_link_content doesn't exist. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1611 of /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
I went to apply the patch mentioned in #7 but realized it's already committed to beta2.
Now I am WSODed with:
Fatal error: Cannot redeclare Drupal\Core\Entity\EntityManager::getActiveFieldStorageDefinitions() in /app/web/core/lib/Drupal/Core/Entity/EntityManager.php on line 235
. Any troubleshooting suggestions or information I can provide? Otherwise I'll just revert back to 8.6.13 and attempt to wait patiently for Layout Builder.Comment #9
plachComment #10
plach@BrightBold:
Thanks for testing the update and reporting back!
The WSOD is definitely caused by the attempt to re-apply the patch, which, as you mentioned, is already part of -beta2. If you revert that you should no longer see it, which leaves us with the first error that is definitely more concerning. If at least error handling behaved correctly, the original state should have been preserved and you should have no tables with a
tmp_
orold_
prefix, however the update itself should still be marked as pending. Is that the case?The first step to allow us to troubleshoot this would be to provide the full stack trace, as @joelpittet did in #4. To do that you should enable verbose logging (add
$config['system.logging']['error_level'] = 'verbose';
to your PHP settings) and run the update again.Also, was the
Update taxonomy terms to be revisionable.
update applied successfully?Comment #11
BrightBoldThanks for the prompt response!
OK, that was sneaky. I had "no"ed all the prompts about applying the patch, so I didn't think I had changed anything in my aborted attempt, but I failed to realize that one hunk got applied unprompted. Reverting that did indeed fix the WSOD.
The good news is I can consistently reproduce this error, and taxonomy update 8701 is being applied successfully.
The bad news is that syslog kicked my ass (I assume that's what system.logging, which was already enabled, is using?) I followed the directions in the docs except that the link for how to restart on MacOS is broken, and in attempting to do that I think I am hung up on System Integrity Protection so I need to be near an outlet before I can reboot as required to disable SIP. Or I need to be told that I'm headed down the wrong path and get some remedial help in logging. If I can get some advice on that I will provide the callstack. (Also I'm in a Lando container if that makes a difference as to where logs go.) Sorry.
Comment #12
BerdirOne tricky thing with those temporary table migrations is that it can break if you tried to upgrade before, even if you restore the database because that will not remove tables created by the update. Most likely not the problem here, the errors I saw related to that look different, but doesn't hurt to make sure that you really start with an empty database when testing. Maybe lando takes care of that, no idea.
Comment #13
BrightBold@Berdir FTW!
I deleted the menu_link_content and menu_link_content_revisions tables before re-importing the database and then it ran successfully. I'm guessing the initial error occurred because I had encountered another error (from contrib) the first time I ran the update (#3030554: Fix 8.7 compatibility problems in ViewsBulkOperationsBulkForm). I didn't think this was relevant to report because I had restored the database after that occurred, but the problem with the tables not getting deleted hadn't occurred to me.
So I think this is a non-issue, but I did save a backup of the database with the tables intact, if for any reason you want me to reproduce the failure again and give you more information.
Thanks all for your help!
Comment #14
plachDo you mean you already had
tmp_
-prefixed tables in the DB before running the update and that deleting those allowed you to complete the update successfully?Comment #15
plachOk, assuming this was an env issue, closing again, feel free to reopen if needed.
Comment #16
BrightBold@plach Deleting the
tmp_
tables didn't fix anything because the temp prefixes were different every time, so they weren't causing a conflict. (When I looked at the database, I had three different pairs of temporary tables from running update three times.) So to get it working I deleted the main (menu_link_content
andmenu_link_content_revisions
) tables.My assumption is that this was caused by the aborted initial update caused by the VBO error I mentioned in #13, so that this isn't a normal condition people will run into. But if you want me to reproduce the failure and any additional information, let me know.
Comment #17
plachSorry, I don't get it.
The update function is supposed to do the following:
tmp_
tables;tmp_
tables;old_
;tmp_
tables to the unprefixed version, thus making them the new storage;old_
tables.I understand that
menu_link_content_revisions
might be a leftover of a previous attempt, although it's surprising that the update was not marked as completed, given that we got to step 4. What I don't get is why you needed to deletemenu_link_content
and where data was copied from in that case.Comment #19
jweirather CreditAttribution: jweirather commentedJust adding a note that this same thing happened to me during the update to the 8.7 release.
@BrightBold's fix above (#13, deleting revision tables) resolved that specific issue for me.
The update process then proceeded beyond that step, but got hung up on the possibly related issue #3040129, where @joelpittet's fix in that issue's #7 comment resolved that subsequent fatal error for me.
Comment #20
frankdesign CreditAttribution: frankdesign commentedI've come across this issue on updating from 8.6.15 to 8.7.0. All contrib modules are latest versions. Tried @BrightBold's fix above #13 but that didn't work for me. Any suggestions?
Thanks
F
Comment #21
slefevre@ccad.edu CreditAttribution: slefevre@ccad.edu commentedI'm encountering this same problem upgrading from 8.6.15 to 8.7
Comment #22
amateescu CreditAttribution: amateescu commentedMy best guess so far is that the
menu_link_content
is already revisionable on your site, maybe if you're using the Multiversion module, so can you try this patch which skips the update function if that's the case?Comment #23
Gkomi CreditAttribution: Gkomi commentedI'm having the same issue after updating from 8.6.15 to 8.7
Comment #24
hvalentim CreditAttribution: hvalentim commentedFix #22 not working here (update from latest 8.6 to 8.7):
[error] Exception thrown while performing a schema update. Cannot rename tmp_602700menu_link_content_revision to menu_link_content_revision: table menu_link_content_revision already exists.
[error] Update failed: menu_link_content_post_update_make_menu_link_content_revisionable
[error] Update aborted by: menu_link_content_post_update_make_menu_link_content_revisionable
[error] Finished performing updates.
Comment #25
amateescu CreditAttribution: amateescu commented@hvalentim, is the site using the Multiversion module or is the
menu_link_content
entity type already revisionable by other means before the update to 8.7.0?Comment #26
frankdesign CreditAttribution: frankdesign commentedPatch #22 didn't work for me either.
Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. Cannot rename tmp_78e7dbmenu_link_content_revision to menu_link_content_revision: table menu_link_content_revision already exists. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1611 of /var/www/vhosts/domain.com/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
I'm not using the the Multiversion module. I haven't specifically set any revisioning for
menu_link_content
but I do have three menu related modules enabled that may (unknown to me) have set revisioning. They are Menu Block, Menu Trail by Path and Link Attributes. I don't see any posts in their issue queues related to 8.7.F
Comment #27
hvalentim CreditAttribution: hvalentim commentedMultiversion module not installed.
As for "is the menu_link_content entity type already revisionable by other means" part, honestly, I have no idea.
Manually deleting both menu_link_content_revision and menu_link_content_field_revision seems to have allowed the updb to go through (complete with apparent success), though.
PS: It may or not be relevant (probably not, I leave you the judgment), but one thing I also noticed in the process was that I had a stray view (which I also deleted):
" [error] No entity type for field field_intervis_distance on view cume_show_intervis
[error] Update failed: menu_link_content_post_update_make_menu_link_content_revisionable
[error] Update aborted by: menu_link_content_post_update_make_menu_link_content_revisionable
[error] Finished performing updates."
Comment #28
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@hvalentim, the views error is quite relevant because I think most of these update problems are caused by
\Drupal\views\EventSubscriber\ViewsEntitySchemaSubscriber::onEntityTypeUpdate()
, which is updating all the existing views, even those that are not dealing with the entity types that are converted to revisionable in 8.7.0 (taxonomy_term
andmenu_link_content
).In case you have a backup of the database before attempting the upgrade to 8.7.0, can you try to delete that view on the backup database and run the update again?
In the meantime, I'll start working on a patch to try and fix
ViewsEntitySchemaSubscriber
.Comment #29
BerdirAs mentioned before, this can also happen if the updated is executed more than once. If you sync your database with e.g. drush sql-sync from production to a test environment, make sure you remove all tables first, with drush sql-drop for example. Otherwise something like this can happen.
Comment #30
plachComment #31
hvalentim CreditAttribution: hvalentim commented"In case you have a backup of the database before attempting the upgrade to 8.7.0, can you try to delete that view on the backup database and run the update again?"
I haven't, sorry (just a very old one :/, which would probably introduce new variables to the debug process).
Comment #32
plach@hvalentim:
Can you check whether the update process created backup tables with the prefix
old_[6-random-chars]
? Those should at least allow you to restore the previous state.Comment #33
dankh CreditAttribution: dankh as a volunteer commentedSame problem here, can't rename table, table exists. Message in french :
In the database I have
tmp_
tables, noold_
tables.Enabled modules in attachment.
Comment #34
vuilThe patch #22 doesn't work for me too.
I already post a similar issue with menu_link_content.post_update here:
https://www.drupal.org/project/drupal/issues/3052318
Comment #35
plach@dankh:
That means the update process didn't get to replace the old tables yet, which are still in place.
Comment #36
hvalentim CreditAttribution: hvalentim commented@plach wrote "Can you check whether the update process created backup tables with the prefix ..."
Well, these were left over:
old_77426emenu_link_content
old_77426emenu_link_content_data
old_c1c4dataxonomy_term_data
old_c1c4dataxonomy_term_field_data
old_c1c4dataxonomy_term__parent
old_e6e203menu_link_content
old_e6e203menu_link_content_data
old_e36e74menu_link_content
old_e36e74menu_link_content_data
+ 21, with names similar to:
tmp_05cf0cmenu_link_content_field_revision
tmp_9e4037menu_link_content_revision
@plach wrote "Those should at least allow you to restore the previous state."
Hum, there is no need for that. As explained, after manually deleting the orphaned old view (including fields no longer existent) + the 2 mentioned tables, the database update process completed successfully. All seems OK now.
Comment #37
vuilComment #38
frankdesign CreditAttribution: frankdesign commentedOk, so this is a little weird. I have reverted the database back to a previous state before trying the update (by importing a clean database dump as opposed to using the Backup Migrate Module). I checked the database and there were no tables for any variation of Menu Link Revisions or Taxonomy Term Revisions. I then ran the update script (without the patch #22) and all worked fine. No idea why it failed the first time. I'll see how I get on with my other websites. I'll report back if there are any issues with them.
However just to note, I checked the database after the update, there are a number of old_.... tables for Menu Link and Taxonomy Terms which I assume should have been deleted once the update was completed. So it looks like there is still an issue somewhere.
F
Comment #39
cmah CreditAttribution: cmah commentedThe question in #17 about which exact tables to delete has not been answered, and there are several misleading comments that seem to indicate that
menu_link_content
should be one of the manually deleted tables. This seems wrong to me.After the first failure of
drush updb
, the only two tables I deleted weremenu_link_content_field_revision
andmenu_link_content_revision
, and then everything worked (although as someone else pointed out, there are now some orphanedtmp_*
tables).Comment #40
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@frankdesign,
Nope, that's "by design" :) See this change record: https://www.drupal.org/node/3046576
I've posted a patch at #3052492: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved that should help a bit in the cases where these updates fail because of an unrelated View can not be saved anymore.
Comment #41
xjmSo just a note for anyone who sees a message that the table already exists: This will also happen if you tried to run the updates once, this update was succcessful but something else failed, and then you tried running updates again again. So if you get an error that the table already exists, look for other error messages earlier on, and try restoring from backup and running the update again (only once) to see what else might have happened.
Comment #42
rshafakian CreditAttribution: rshafakian commentedI'm getting a similar error: Ran composer update for core and then on updatedb i get the following:
I then have old_menu_link tables, but no tmp tables. If i run updatedb again then i get the tmp tables and i get the error
Cannot rename tmp_57da5fmenu_link_content_revision to menu_link_content_revision: table menu_link_content_revision already exists.
I've tried deleting the tmp/old tables but this did not work. I also tried deleting the menu_link_content_revision tables, but this did not work at all. Any thoughts?
Comment #43
Berdir> I then have old_menu_link tables, but no tmp tables. If i run updatedb again
then i get the tmp tables and i get the error Cannot rename
tmp_57da5fmenu_link_content_revision to menu_link_content_revision: table
menu_link_content_revision already exists.
That is exactly what I meant in #12 and #29. You can *not* run updates again if you didn't properly clean your database, drop everything, import the backup, start again. Which should mean you will run again in that strange "Placeholders must have a trailing [] if they are to be expanded with an array of values. " error, which I think is a different one. We need a backtrace on that, could be a hook/event that is reacting to the change somehow.
Edit: The question is whether we can or should do something about that, but it seems tricky to deal with, just deleting existing tables could result in actually deleting data if some other module created them.
Comment #44
TehJott CreditAttribution: TehJott as a volunteer commentedThe following workaround helped for me (with the "Placeholders must have a trailing [] if they are to be expanded with an array of values. " error):
Before the update I added English as a language and set it as default. (My site is in German).
Then my views disappeared.
Then I did the update which did run without errors.
Then I did set the default language back to German and my views reappeared and the update was done.
(I came to this approach after including some var_dumps into the exception handler.)
Comment #45
jaims-dev CreditAttribution: jaims-dev as a volunteer commentedVery same thing is happening to me:
Error: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. No es posible renombrar tmp_e8a250menu_link_content_revision a menu_link_content_revision: la tabla menu_link_content_revision ya existe
If I go then and remove the tables menu_link_content_field_revision and menu_link_content_revision, and then re-run /update.php, it ends up with the error 'Placeholders must have a trailing [] if they are to be expanded with an array of values', and my site breaks.
Comment #46
TehJott CreditAttribution: TehJott as a volunteer commentedEverything went fine after the update via the proposed workaround save one small thing which I have noticed only now:
If calling
admin/reports/dblog
I get the following warning (and it seems I get it only there)
This isn't a serious problem but perhaps it helps at hunting the error.
Comment #47
danylevskyiThe patch didn't work for me.
Comment #48
danylevskyiComment #49
plach@danylevskyi:
Please post the original error you got: as explained above, the error reported in the issue title occurs when trying an update a second time without restoring the database properly. It's likely that the patch at #3052492: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved will fix the original issue, but you still need to start from a clean DB.
Comment #50
danylevskyi@plach, this error occurs when I'm trying to run updates on the copy of the production database.
Comment #51
danylevskyiSorry. Our DB was not properly restored.
We can't check the patch right now because we are struggling with another problem blocking this update (2006 MySQL server has gone away)
So, setting Needs Review status.
Comment #52
rshafakian CreditAttribution: rshafakian commentedHere's what worked for me:
https://www.drupal.org/project/drupal/issues/3052318#comment-13094197
Comment #53
danylevskyiIt worked for me! Thanks!
Comment #54
mohamed7afezz CreditAttribution: mohamed7afezz commentedI have same issue after upgrading to 8.7.0. It was during database updates, it got following error:
Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. Cannot rename tmp_4c7facmenu_link_content_revision to menu_link_content_revision: table menu_link_content_revision already exists. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1611 of /srv/bindings/5aeed456a7c7472eb00641fc2f6f0124/code/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Then, I drop two tables as per link:
https://www.drupal.org/project/drupal/issues/3052318#comment-13094197
DROP TABLE `menu_link_content_revision`;
DROP TABLE `menu_link_content_field_revision`;
After that I run update.php again and have different issue:
The "profiles" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 150 ....
Finally, it's work after I deleted view with name "profiles", drop two tables and run update.php.
Comment #55
emanuelrighetto CreditAttribution: emanuelrighetto as a volunteer commentedWith patch #22
updb -y
was successful.But I have a question: as per comment #17 the update function should optionally drop
old_
tables, how can I achieve the drop of those table during the update process? After they are still present in the database.Comment #56
flocondetoileSolution from https://www.drupal.org/project/drupal/issues/3052318#comment-13097996 solved this issue for me. As told in #49
Comment #57
plach@emanuelrighetto:
See https://www.drupal.org/node/3046576
Comment #58
emanuelrighetto CreditAttribution: emanuelrighetto as a volunteer commented@plach OK,
$settings['entity_update_backup'] = FALSE;
in settings.php did the work.I ran update on a restored backup to check this aspect.
Thank you!
Comment #59
tamarackmedia CreditAttribution: tamarackmedia commentedThe notes from #39 worked for me. The first error I received regarded a view (that was already disabled). I deleted the view and tried again and then got the error:
Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. Cannot rename tmp_154b4cmenu_link_content_revision to menu_link_content_revision: table menu_link_content_revision already exists. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1611...
I then used Backup and Migrate to restore a DB version from before the update, deleted the offending view again, ran update.php, got a new error, and then dropped the two tables: menu_link_content_field_revision and menu_link_content_revision. Then I ran update.php and it worked.
Comment #60
jimafisk CreditAttribution: jimafisk at Jantcu commented#39 worked. I needed to drop a few more tables though:
Then I could run
drush updb
successfully.EDIT: This now throws the following error when trying to edit certain pages:
Comment #61
caspervoogt CreditAttribution: caspervoogt at Plethora commentedI encountered this too. In my case the Views Bulk Operations module generated a fatal error during the DB updates. #13 mentions that too. I updated VBO accordingly, restored my DB to the version just prior to the DB updates, then tried again, and it worked fine.
Comment #62
tibezh CreditAttribution: tibezh as a volunteer and at Drupal Ukraine Community commented#56 comment solved this issue. This is an issue with non-english sites.
But need to apply a patch before update db. If you already updated and got an error, then just remove "menu_link_content_revision" and "menu_link_content_field_revision"
Don't forget about backups!
Comment #63
selinav CreditAttribution: selinav commentedI've the same issue for update a french / english site.
From 8.6.13 to 8.7.1
If I delete tables before update script :
- menu_link_content_revision
- menu_link_content_field_revision
I've got another message after :
What should I do to succeed the update script ?
Thanks in advance
Comment #64
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@selinav, you can either apply the patch from #3052492-13: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved and restart the update, or wait until 8.7.2 is released with that fix included.
@jimafisk, if the revision tables for taxonomy terms and menu links don't exist after running the database updates, you should restore a database backup and re-run the updates. The advice above also applies, either include that patch or update directly to 8.7.2 when it is released.
Comment #65
jmbsvicetto CreditAttribution: jmbsvicetto as a volunteer commentedI've been hit by both issues 2999869 and 3039586.
When updating from drupal 8.6.15 to 8.7.1, I initially hit issue 2999869 and on following attempts I hit issue 3039586.
I ended up tracing the issue to having only the PT language installed on the drupal instance. After installing the EN language (and after removing the tmp_* and old_* tables), I was finally able to update without hitting any issues.
Comment #66
vinyl_roads#44 works form me : I've installed English language and set it as defaults language. I could update ands then revert to French.
Comment #67
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedI am facing the same issue on my multilanguage page having german as the default language.
Comment #68
quixxel CreditAttribution: quixxel commentedlike #67 same issue here having multilanguage page with german as the default language
patch#44 is not working for me.
Comment #69
FirstSanny CreditAttribution: FirstSanny commentedIf your database is located in a different scheme, than 'website', then maybe you should read my comment here.
With this you probably can run the update successfully, but most of the tables are going in the wrong scheme. So i wouldn't recommend to update now.
Comment #70
TiMESPLiNTER CreditAttribution: TiMESPLiNTER commented@amateescu I have now Drupal 8.7.2 but still the same problem when running the update script.
Comment #71
Anonymous (not verified) CreditAttribution: Anonymous commentedAfter updating from 8.6.15 -> 8.7.2, #39 works for me!
Thanks @chickenofeathers!
Comment #72
vuilAfter an update from 8.6.16 -> 8.7.2, #39 works, thanks!
Comment #73
vuilComment #74
vuilComment #75
cilefen CreditAttribution: cilefen as a volunteer commentedIt is “fixed” only by workarounds.
Comment #76
robpowellUpdating from 8.6.16 to 8.7.3 and got above error reported. Restored from production database and ran the delete statements per #39
Ran drush entup -y && drush updb -y and got a similar error but this time with taxonomy_term.
I reviewed #3052464 and confirmed while my issue wasn't exactly the same it wouldn't hurt to confirm that my data was not corrupt. Confirmed that the status column had no NULLS.
Reviewing @jimafisk comment #60, I went ahead and restored from back up and this time deleted more tables:
Ran drush entup -y && drush updb -y and this time it completed. I confirmed that the tables exist and edit workflow for nodes work.
Comment #77
bdanin CreditAttribution: bdanin commentedAfter deleting my database by dropping all tables, and then restoring from a previous version where no 8.7 upgrade was attempted, Patch #22 does not work. I've also tried with this patch installed before the
Comment #78
audacus CreditAttribution: audacus commentedI use following workaround to prevent multiple update attempts.
Comment #79
vuilUpdate the #78 patch.
Apply Drupal coding standards and update
t()
to use$this->t()
instead.Comment #80
vuilComment #81
bdanin CreditAttribution: bdanin commentedNot sure RTBC should be applied to your own patch, so putting this back to "needs review". I don't have time to test the patch at this moment, but I was able to resolve my issue with dropping the tables as reported earlier. I had to keep adding tables to drop until I no longer had the error, and was left with this set of tables before being able to run the database updates:
Comment #82
liber_tI have an error to apply this patch
Error: Using $this when not in object context in menu_link_content_post_update_make_menu_link_content_revisionable() (line 24 of /project/web/core/modules/menu_link_content/menu_link_content.post_update.php)
Comment #83
liber_tIt's same path than #82 but just add core directory ... in path
Comment #84
vuilComment #85
vuilComment #86
renatogI agree with @bdanin on #81
I applied the patch #83 and the error continued. Look that:
Before patch:
After patch:
So I followed the suggestion on #81 to drop tables. And works good (after drop table(s))
Result:
So, it works but is necessary to drop the tables, so the correct status is "Needs Work" IMO.
Best,
Comment #87
bwoods CreditAttribution: bwoods as a volunteer commented#81 seemed to have worked for me as well. Thanks!
Comment #88
Znak CreditAttribution: Znak at Drupal Ukraine Community for Drupal Ukraine Community commentedI applied the patch but after this, I had problems. When I open menu link or taxonomy term I get an error. I recreated patch for this issue and add code for remove revision tables for menu_link_content and taxonomy term before the code which update database. I think it's a bad solution, but you can use my patch as a temporary solution.
Comment #89
vuilComment #90
vuilComment #91
renatogI didn't test yet but #88 makes sense.
Comment #92
catch#88 isn't committable - it's allowing the update to run twice, whereas it should only run once.
Is anyone running into this issue for reasons other than trying to re-run a failed update?
Comment #93
mh.marouan CreditAttribution: mh.marouan commentedSolution for me : I deleted all tmp table and taxonomy revision table then run update.php.
Comment #94
renatogYeah! I used the same solution and really works good but to fix the issue we can create an "automatic solution", without a "manual drop table"
Tks Guys!
Comment #95
plachAs @catch mentioned in #92, the only possible automated solution is to figure out what's causing the error in the first run and fix that. We cannot support running the update twice, although it's good to know that there's a workaround (and you're welcome to post a script automating that :) while we figure out how to proper fix this.
What would really help there would be being able to replicate the failure reliably, unless that has already been fixed by 8.7.2 and following and, as @catch suggested, we're "only" dealing with the fallout of the now-fixed issues here.
If anyone here is getting the reported error on the first update run on a fresh DB, that would really be useful to know. Even more so, if any clue for how to reproduce the error is provided.
Comment #96
plachUpdated the IS to help newcomers to figure out what's going on. Setting to needs more info per #92 and #95.
Comment #97
plachComment #98
plachAdded a not about the
old_
tables.Comment #99
gmaka CreditAttribution: gmaka as a volunteer and commentedI'm able to reproduce this issue.
Here is the first error I get after `updb` if I run `updb` again, I get the tmp table error mentioned above.
`TypeError: Argument 1 passed to Drupal\views\EventSubscriber\ViewsEntitySchemaSubscriber::Drupal\views\EventSubscriber\{closure}() must be of the type array, null given, called in /core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php on line 279`
I've added this patch a while back that fixes the first error, and then the second error is a non-issue.
https://www.drupal.org/project/drupal/issues/3006815
Comment #100
gmaka CreditAttribution: gmaka as a volunteer and commentedUPDATE,
So the initial error I was getting, that caused the second error (this one) was caused by a broken/missing handler in a view. (the patch noted in my previous comment merely masked the broken config, thanks, Lendude!)
Hopefully this will help someone experiencing this. If you are getting the `TypeError: Argument 1` error first, and then getting the `Cannot rename tmp_` on subsequent db updates. Make sure you don't have any broken configs.
Comment #101
plachThanks @gmaka, that's helpful!
Comment #102
mmjvb CreditAttribution: mmjvb as a volunteer commentedDisagree with #92 and #95. It should be allowed to run the update multiple times. How else are you going to succeed updating!!!
Once the data corruption is fixed you should be able to update again. Current implementation doesn't allow this, it should!
Disagree on the patch although #88 is a valid workaround for some situations.
The real fix would be to catch these kind of errors as reported in #99/#100 and log those for further dealing with. These kind of errors shouldn't make the update fail. Same thing goes for missing values for attributes now considered NOT NULL, either provide a default or log them.
See https://en.wikipedia.org/wiki/Reentrancy_(computing)
Comment #103
plach@mmjvb:
You are free (and welcome :) to disagree, but #92 and #95 are describing how the update process as whole is designed to work right now, not how we would like it to work. You can open a separate issue suggesting to change this behavior, but this is not the right place to do that.
As things stand, the solutions implying a repeated execution of the update cannot be accepted. You may successfully able to run the update twice or more, but the only officially supported process is:
Agreed, we should focus on fixing the errors causing the first update failures. To address those I reopened #3006815: ViewsEntitySchemaSubscriber may fail when a view has a broken handler.
Comment #104
plachTo clarify, I'd like to keep this issue to try and figure out if the reported error can actually happen on the first run, this is the reason for the "Needs more info" status.
Comment #105
nishantkumar155 CreditAttribution: nishantkumar155 as a volunteer and at Cognizant Technology Solutions commentedi have used 88 patch ,it works but after updb , menu link is not working.
Comment #106
plachFYI #3006815: ViewsEntitySchemaSubscriber may fail when a view has a broken handler was committed and will be part of 8.7.7.
Comment #107
donaldp CreditAttribution: donaldp commentedDeleted message. My issue was being caused by unknowingly not completely deleting a database before overwriting with an different version so the new tables where already present.
Comment #108
nishantkumar155 CreditAttribution: nishantkumar155 as a volunteer and at Cognizant Technology Solutions commentedAs i used #88 but it was failing i have upaded the patch #88 now menu link are working.
Comment #109
nishantkumar155 CreditAttribution: nishantkumar155 as a volunteer and at Cognizant Technology Solutions commentedRe-uploading the #108 patch.
Comment #110
nishantkumar155 CreditAttribution: nishantkumar155 as a volunteer and at Cognizant Technology Solutions commentedRe-uploading the #108 patch. diff was wrong.
Comment #111
jppo CreditAttribution: jppo commentedHello,
I get the same problem with message (use of drush updatedb) :
----------------------------------------------------------------------------------------------------------
Do you wish to run all pending updates? (y/n): y
session_id(): Cannot change session id when headers already sent AbstractProxy.php:94 [warning]
Après la mise à jour de menu_link_content [ok]
Failed: Drupal\Core\Entity\EntityStorageException : Exception thrown while performing a schema update. [error]
Impossible de renommer tmp_3f4139menu_link_content_revision en menu_link_content_revision : la table
menu_link_content_revision existe déjà. dans
Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (ligne 1607 de
/var/www/consult/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
-----------------------------------------------------------------------------------------------------------
It is the second time (third time) I see this error during an update.
I have 2 sites using allways the same Drupal versions and I do the update at the same time.
I see that problem only on 1 site.
Even if I execute the rename "manually", drop the "real" table, rename the "tmp...." to real name the problem
persist at next upgrade.
I didn't see differences while comparing tables columns ... I can't even understand the problem.
I know very well Mysql/MariaDB but can't know what updates are performed ... and why they crashed.
There are differences between my two sites : they are not using both all the same modules/plugins but as far as I can see the tables are the same between the two sites (columns are the same, their types are the same...).
Where are the differences leading to a crash on one side and run silently on the other.
As I am not a PHP Guru I can't really help to find the real problem.
Regards
JP P
Comment #112
jppo CreditAttribution: jppo commentedA little complement :
As i made the upgrade on the other site I get a polite message :
----------------------------------------------------------------
drush.phar updatedb
No database updates required
----------------------------------------------------------------
Where are stored that bloody upgrades which lead to that problem ...
On the first site (with weird messages the complete trace is :
-------------------------------------------------------------------------------------------------------------------
drush.phar updatedb
The following updates are pending:
menu_link_content module :
Update custom menu links to be revisionable.
system module :
Initialize 'expand_all_items' values to system_menu_block.
Clear the menu cache. @see https:www.drupal.orgprojectdrupalissues3044364
taxonomy module :
Update taxonomy terms to be revisionable.
Remove the 'hierarchy' property from vocabularies.
views module :
Update exposed filter blocks label display to be disabled.
Rebuild cache to allow placeholder texts to be translatable.
Do you wish to run all pending updates? (y/n): y
session_id(): Cannot change session id when headers already sent AbstractProxy.php:94 [warning]
Après la mise à jour de menu_link_content [ok]
Failed: Drupal\Core\Entity\EntityStorageException : Exception thrown while performing a schema update. [error]
Impossible de renommer tmp_3f4139menu_link_content_revision en menu_link_content_revision : la table
menu_link_content_revision existe déjà. dans
Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (ligne 1607 de
/var/www/consult/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Cache rebuild complete. [ok]
Finished performing updates.
------------------------------------------------------------------------------------------------------------
I hope this helps
Regards
JP P
Comment #113
gpap CreditAttribution: gpap commented[deleted]
Comment #115
avitslv CreditAttribution: avitslv commentedUpdated @nishantkumar155 #110 patch removing the project specific fields per @gpap suggestion.
Comment #116
avitslv CreditAttribution: avitslv commentedFixing the naming of the #115 patch and displaying previous files.
Comment #117
vuilI added my employer only.
Comment #118
AstonVictor CreditAttribution: AstonVictor at DevBranch commentedComment #119
udhay9321 CreditAttribution: udhay9321 commentedI am upgrading drupal core from 8.6 to 8.7 initially I got following error
[error] Exception thrown while performing a schema update. Cannot rename tmp_a207a5menu_link_content_revision to menu_link_content_revision: table menu_link_content_revision already exists.
Then i have applied #118 now i am getting following error.
[error] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'database.taxonomy_term__scheduled_transition_date' doesn't exist: SELECT t.*
FROM
{taxonomy_term__scheduled_transition_date} t
WHERE (entity_id IN (:db_condition_placeholder_0)) AND (deleted = :db_condition_placeholder_1) AND (langcode IN (:db_condition_placeholder_2, :db_condition_placeholder_3, :db_condition_placeholder_4))
ORDER BY delta ASC; Array
(
[:db_condition_placeholder_0] => 4
[:db_condition_placeholder_1] => 0
[:db_condition_placeholder_2] => en
[:db_condition_placeholder_3] => und
[:db_condition_placeholder_4] => zxx
)
[error] Update failed: menu_link_content_post_update_make_menu_link_content_revisionable
[error] Update aborted by: menu_link_content_post_update_make_menu_link_content_revisionable
[error] Finished performing updates.
The table taxonomy_term__scheduled_transition_date was not in database before update. Please let me know if any one facing similar issue.
Comment #120
CH man CreditAttribution: CH man commentedHi,
when i updating Drupal core from 8.6 to 8.7.0 i had the same problem.
I created the patchs and they worked for me .
thanks
Comment #122
firewaller CreditAttribution: firewaller commented+1
Comment #125
andrimont CreditAttribution: andrimont commentedHello, my database is full of tmp_cxxxxxxx tables.
It might have happened with Drupal8. Now it is upgraded to D9 but I noticed theses tables related to content type that are corrupted.
What should I do ? Can I just delete these tables ?
Thanks for help.
Regards.
Comment #127
quietone CreditAttribution: quietone at PreviousNext commentedThank you to everyone who worked on this problem!
This issue was set to Postponed (maintainer needs more info) in #103, Aug 2019, to determine if the reported error can actually happen on the first run. There has been no response to that query in the intervening 3 years.
Therefore, closing as outdated. If this is incorrect reopen the issue, by setting the status to 'Active', and add a comment explaining what still needs to be done.
Thanks!