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:

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

CommentFileSizeAuthor
#120 patch2b.patch1.14 KBCH man
#120 patch1b.patch928 bytesCH man
#120 patch0.patch2.31 KBCH man
#118 cannot_rename_tmp_2362aemenu_link_content_revision_to_menu_link_content_revision-3039586-118.patch2.28 KBAstonVictor
#116 cannot_rename_tmp_2362aemenu_link_content_revision_to_menu_link_content_revision-3039586-116.patch1.99 KBavitslv
#115 revision-update-issue.patch1.99 KBavitslv
#110 cannot_rename_tmp_2362aemenu_link_content_revision_to_menu_link_content_revision-3039586-110.patch2.36 KBnishantkumar155
#109 cannot_rename_tmp_2362aemenu_link_content_revision_to_menu_link_content_revision-3039586-109.patch2.36 KBnishantkumar155
#108 cannot_rename_tmp_2362aemenu_link_content_revision_to_menu_link_content_revision-3039586-108.patch2.36 KBnishantkumar155
#88 cannot_rename_tmp_2362aemenu_link_content_revision_to_menu_link_content_revision-3039586-88.patch2.08 KBZnak
#86 Img2.png29.23 KBrenatog
#86 Img1.png37.63 KBrenatog
#86 Img.png57.29 KBrenatog
#83 cannot_rename_tmp_2362aemenu_link_content_revision_to_menu_link_content_revision-3039586-83.patch1.79 KBliber_t
#82 interdiff_79-82.txt1.81 KBliber_t
#82 cannot_rename_tmp_2362aemenu_link_content_revision_to_menu_link_content_revision-3039586-82.patch1.76 KBliber_t
#79 3039586-79.patch1.81 KBvuil
#78 3039586-78-prevent-multiple-update-attempts.patch1.79 KBaudacus
#33 enabled-modules.txt10.91 KBdankh
#22 3039586-22.patch896 bytesamateescu
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joelpittet created an issue. See original summary.

joelpittet’s picture

joelpittet’s picture

Issue summary: View changes
joelpittet’s picture

The callstack while debugging with @amateescu:

SqlContentEntityStorage.php:428, Drupal\taxonomy\TermStorage->getFromStorage()
SqlContentEntityStorage.php:399, Drupal\taxonomy\TermStorage->doLoadMultiple()
EntityStorageBase.php:291, Drupal\taxonomy\TermStorage->loadMultiple()
TaxonomyIndexTid.php:396, Drupal\taxonomy\Plugin\views\filter\TaxonomyIndexTid->calculateDependencies()
PluginDependencyTrait.php:51, Drupal\views\Plugin\views\display\DefaultDisplay->getPluginDependencies()
PluginDependencyTrait.php:69, Drupal\views\Plugin\views\display\DefaultDisplay->calculatePluginDependencies()
DisplayPluginBase.php:960, array_walk()
DisplayPluginBase.php:960, Drupal\views\Plugin\views\display\DefaultDisplay->calculateDependencies()
PluginDependencyTrait.php:51, Drupal\views\Entity\View->getPluginDependencies()
PluginDependencyTrait.php:69, Drupal\views\Entity\View->calculatePluginDependencies()
View.php:290, Drupal\views\Entity\View->calculateDependencies()
ConfigEntityBase.php:319, Drupal\views\Entity\View->preSave()
View.php:300, Drupal\views\Entity\View->preSave()
EntityStorageBase.php:490, Drupal\Core\Config\Entity\ConfigEntityStorage->doPreSave()
EntityStorageBase.php:445, Drupal\Core\Config\Entity\ConfigEntityStorage->save()
ConfigEntityStorage.php:263, Drupal\Core\Config\Entity\ConfigEntityStorage->save()
EntityBase.php:394, Drupal\views\Entity\View->save()
ConfigEntityBase.php:613, Drupal\views\Entity\View->save()
ViewsEntitySchemaSubscriber.php:202, Drupal\views\EventSubscriber\ViewsEntitySchemaSubscriber->onEntityTypeUpdate()
EntityTypeEventSubscriberTrait.php:47, Drupal\views\EventSubscriber\ViewsEntitySchemaSubscriber->onEntityTypeEvent()
ContainerAwareEventDispatcher.php:111, call_user_func:{/var/www/sites/cs8/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:111}()
ContainerAwareEventDispatcher.php:111, Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()
EntityTypeListener.php:132, Drupal\Core\Entity\EntityTypeListener->onFieldableEntityTypeUpdate()
EntityDefinitionUpdateManager.php:229, Drupal\Core\Entity\EntityDefinitionUpdateManager->updateFieldableEntityType()
menu_link_content.post_update.php:100, menu_link_content_post_update_make_menu_link_content_revisionable()
update.inc:247, update_invoke_post_update()
batch.inc:295, _batch_process()
batch.inc:137, _batch_do()
batch.inc:93, _batch_page()
DbUpdateController.php:186, Drupal\system\Controller\DbUpdateController->handle()
UpdateKernel.php:115, call_user_func_array:{/var/www/sites/cs8/web/core/lib/Drupal/Core/Update/UpdateKernel.php:115}()
UpdateKernel.php:115, Drupal\Core\Update\UpdateKernel->handleRaw()
UpdateKernel.php:76, Drupal\Core\Update\UpdateKernel->handle()
update.php:28, {main}()

Commenting out $view->trustData()->save(); from core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php:202

Allowed these to go through!

plach’s picture

amateescu’s picture

amateescu’s picture

Status: Active » Closed (duplicate)
BrightBold’s picture

Status: Closed (duplicate) » Active

Hmm. 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.

plach’s picture

Issue tags: +8.7.0 beta testing
plach’s picture

Priority: Normal » Major
Status: Active » Postponed (maintainer needs more info)

@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_ or old_ 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?

BrightBold’s picture

Status: Postponed (maintainer needs more info) » Active

Thanks 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.

Berdir’s picture

One 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.

BrightBold’s picture

@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!

plach’s picture

I deleted the menu_link_content and menu_link_content_revisions tables before re-importing the database and then it ran successfully.

Do 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?

plach’s picture

Status: Active » Fixed

Ok, assuming this was an env issue, closing again, feel free to reopen if needed.

BrightBold’s picture

@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 and menu_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.

plach’s picture

Sorry, I don't get it.

The update function is supposed to do the following:

  1. create tmp_ tables;
  2. copy data from the original tables to the tmp_ tables;
  3. rename the original tables to old_;
  4. rename the tmp_ tables to the unprefixed version, thus making them the new storage;
  5. optionally drop 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 delete menu_link_content and where data was copied from in that case.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

jweirather’s picture

Just 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.

frankdesign’s picture

I'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

slefevre@ccad.edu’s picture

I'm encountering this same problem upgrading from 8.6.15 to 8.7

Post updating menu_link_content                                             [ok]
...
Post updating menu_link_content                                             [ok]
Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown      [error]
while performing a schema update. Cannot rename
tmp_df90d0menu_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 /code/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
amateescu’s picture

My 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?

Gkomi’s picture

I'm having the same issue after updating from 8.6.15 to 8.7

hvalentim’s picture

Fix #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.

amateescu’s picture

@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?

frankdesign’s picture

Patch #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

hvalentim’s picture

Multiversion 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."

amateescu’s picture

@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 and menu_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.

Berdir’s picture

As 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.

plach’s picture

Component: taxonomy.module » menu_link_content.module
hvalentim’s picture

"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).

plach’s picture

@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.

dankh’s picture

FileSize
10.91 KB

Same problem here, can't rename table, table exists. Message in french :

>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [error]  Exception thrown while performing a schema update. Impossible de renommer tmp_c51e73menu_link_content_revision en menu_link_content_revision : la table menu_link_content_revision existe déjà. 
>  [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. 

In the database I have tmp_ tables, no old_ tables.

tmp_c51e73menu_link_content_field_revision
tmp_c51e73menu_link_content_revision

Enabled modules in attachment.

vuil’s picture

The 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

plach’s picture

@dankh:

In the database I have tmp_ tables, no old_ tables.

That means the update process didn't get to replace the old tables yet, which are still in place.

hvalentim’s picture

@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.

vuil’s picture

frankdesign’s picture

Ok, 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

cmah’s picture

The 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 were menu_link_content_field_revision and menu_link_content_revision, and then everything worked (although as someone else pointed out, there are now some orphaned tmp_* tables).

amateescu’s picture

@frankdesign,

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.

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.

xjm’s picture

So 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.

rshafakian’s picture

I'm getting a similar error: Ran composer update for core and then on updatedb i get the following:

[notice] Update started: system_update_8701
>  [notice] Update completed: system_update_8701
>  [notice] Update started: comment_update_8700
>  [notice] Update completed: comment_update_8700
>  [notice] Update started: system_update_8702
>  [notice] Update completed: system_update_8702
>  [notice] Update started: comment_update_8701
>  [notice] Update completed: comment_update_8701
>  [notice] Update started: content_moderation_update_8700
>  [notice] Update completed: content_moderation_update_8700
>  [notice] Update started: file_update_8700
>  [notice] Update completed: file_update_8700
>  [notice] Update started: node_update_8700
>  [notice] Update completed: node_update_8700
>  [notice] Update started: taxonomy_update_8701
>  [notice] Update completed: taxonomy_update_8701
>  [notice] Update started: comment_post_update_add_ip_address_setting
>  [notice] Update completed: comment_post_update_add_ip_address_setting
>  [notice] Update started: content_moderation_post_update_entity_display_dependencies
>  [notice] Update completed: content_moderation_post_update_entity_display_dependencies
>  [notice] Update started: content_moderation_post_update_set_default_moderation_state
>  [notice] Update completed: content_moderation_post_update_set_default_moderation_state
>  [notice] Update started: content_moderation_post_update_set_views_filter_latest_translation_affected_revision
>  [notice] Update completed: content_moderation_post_update_set_views_filter_latest_translation_affected_revision
>  [notice] Update started: layout_discovery_post_update_recalculate_entity_form_display_dependencies
>  [notice] Update completed: layout_discovery_post_update_recalculate_entity_form_display_dependencies
>  [notice] Update started: layout_discovery_post_update_recalculate_entity_view_display_dependencies
>  [notice] Update completed: layout_discovery_post_update_recalculate_entity_view_display_dependencies
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [error]  Placeholders must have a trailing [] if they are to be expanded with an array of values. 
>  [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. 

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?

Berdir’s picture

> 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.

TehJott’s picture

The 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.)

jaims-dev’s picture

Very 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.

TehJott’s picture

Everything 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)

Warning: Illegal string offset 'value' in Drupal\views\Plugin\views\area\Text->preQuery() (line 50 of core/modules/views/src/Plugin/views/area/Text.php).

Drupal\views\Plugin\views\area\Text->preQuery() (Line: 1011)
Drupal\views\ViewExecutable->_preQuery() (Line: 1233)
Drupal\views\ViewExecutable->build() (Line: 390)
Drupal\views\Plugin\views\display\PathPluginBase->execute() (Line: 180)
Drupal\views\Plugin\views\display\Page->execute() (Line: 1630)
Drupal\views\ViewExecutable->executeDisplay('page', Array) (Line: 77)
Drupal\views\Element\View::preRenderViewElement(Array)
call_user_func(Array, Array) (Line: 378)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

This isn't a serious problem but perhaps it helps at hunting the error.

danylevskyi’s picture

The patch didn't work for me.

danylevskyi’s picture

Status: Needs review » Needs work
plach’s picture

@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.

danylevskyi’s picture

@plach, this error occurs when I'm trying to run updates on the copy of the production database.

danylevskyi’s picture

Status: Needs work » Needs review

Sorry. 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.

rshafakian’s picture

danylevskyi’s picture

It worked for me! Thanks!

mohamed7afezz’s picture

I 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.

emanuelrighetto’s picture

With 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.

flocondetoile’s picture

Solution from https://www.drupal.org/project/drupal/issues/3052318#comment-13097996 solved this issue for me. As told in #49

plach’s picture

emanuelrighetto’s picture

@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!

tamarackmedia’s picture

The 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.

jimafisk’s picture

#39 worked. I needed to drop a few more tables though:

DROP TABLE `menu_link_content_revision`;
DROP TABLE `menu_link_content_field_revision`;
DROP TABLE `taxonomy_term_revision`;
DROP TABLE `taxonomy_term_field_revision`;
DROP TABLE `taxonomy_term_revision__parent`;

Then I could run drush updb successfully.

EDIT: This now throws the following error when trying to edit certain pages:

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Core\Database\DatabaseExceptionWrapper</em>: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'my_db.menu_link_content_revision' doesn't exist: SELECT revision.revision_id AS revision_id, revision.langcode AS langcode, revision.revision_default AS revision_default, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log_message AS revision_log_message, base.id AS id, base.bundle AS bundle, base.uuid AS uuid, CASE base.revision_id WHEN revision.revision_id THEN 1 ELSE 0 END AS isDefaultRevision
caspervoogt’s picture

I 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.

tibezh’s picture

#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!

selinav’s picture

I'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 :

module menu_link_content
Mettre à jour make_menu_link_content_revisionable

    Échec : InvalidArgumentException : Placeholders must have a trailing [] if they are to be expanded with an array of values. dans Drupal\Core\Database\Connection->expandArguments() (ligne 735 de C:\wamp64\www\fta2\core\lib\Drupal\Core\Database\Connection.php).

What should I do to succeed the update script ?

Thanks in advance

amateescu’s picture

@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.

jmbsvicetto’s picture

I'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.

vinyl_roads’s picture

#44 works form me : I've installed English language and set it as defaults language. I could update ands then revert to French.

sgurlt’s picture

I am facing the same issue on my multilanguage page having german as the default language.

quixxel’s picture

like #67 same issue here having multilanguage page with german as the default language
patch#44 is not working for me.

FirstSanny’s picture

If 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.

TiMESPLiNTER’s picture

@amateescu I have now Drupal 8.7.2 but still the same problem when running the update script.

Anonymous’s picture

After updating from 8.6.15 -> 8.7.2, #39 works for me!

Thanks @chickenofeathers!

vuil’s picture

After an update from 8.6.16 -> 8.7.2, #39 works, thanks!

vuil’s picture

Status: Needs review » Fixed
vuil’s picture

Status: Fixed » Closed (fixed)
cilefen’s picture

Status: Closed (fixed) » Active

It is “fixed” only by workarounds.

robpowell’s picture

Updating from 8.6.16 to 8.7.3 and got above error reported. Restored from production database and ran the delete statements per #39

DROP TABLE `menu_link_content_revision`;
DROP TABLE `menu_link_content_field_revision`;

Ran drush entup -y && drush updb -y and got a similar error but this time with taxonomy_term.

Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. Cannot rename tmp_9f49cataxonomy_term_revision to [error]
taxonomy_term_revision: table taxonomy_term_revision already exists. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1611 of
/home/vagrant/docroot/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

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:

DROP TABLE `menu_link_content_revision`;
DROP TABLE `menu_link_content_field_revision`;
DROP TABLE `taxonomy_term_revision`;
DROP TABLE `taxonomy_term_field_revision`;
DROP TABLE `taxonomy_term_revision__parent`;

Ran drush entup -y && drush updb -y and this time it completed. I confirmed that the tables exist and edit workflow for nodes work.

bdanin’s picture

After 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

$ drush update drupal/core --with-all-dependencies                                                                                                                                                                                                                                                              1/6:	https://packages.drupal.org/8/drupal/provider-2018-1$a7eba8ee3def5ca343c35e28fe84b87332fa755322161fb94294f0d9197de5f3.json
    2/6:	https://packages.drupal.org/8/drupal/provider-2018-4$0d8bbfb4d6183e0dfec8817f128bfae47d34b219de97c6320650fe5d0b1cceb3.json
    3/6:	https://packages.drupal.org/8/drupal/provider-2018-2$ffe1dc7f43b6300dc5879c919f3afd93947c6ed830d91f636eceac2c04220803.json
    4/6:	https://packages.drupal.org/8/drupal/provider-2019-2$738431aa4f3e1175e87a4f66a622870cf02556e908049e455cd5631821c21172.json
    5/6:	https://packages.drupal.org/8/drupal/provider-2019-1$612c6c819c8e15955e44f0f210e866fa007e81c37e131c2ccbb88731423b3d83.json
    6/6:	https://packages.drupal.org/8/drupal/provider-2018-3$89ac5cb7fcac8be352e62b5a4d525f55f103932943be043bc41fdcffd82f297c.json
    Finished: success: 6, skipped: 0, failure: 0, total: 6
    1/1:	https://asset-packagist.org/p/provider-latest/b9d6ca40fca5225bf20d106ebb62b7ea2fd0727ff51aeaa043bd085735337674.json
    Finished: success: 1, skipped: 0, failure: 0, total: 1
    1/12:	http://repo.packagist.org/p/provider-archived$b76a318b72f1e34beb842aea61012f08337203c4f554aabed933f5a66d70056e.json
    2/12:	http://repo.packagist.org/p/provider-latest$c01e62782122b183bf695581c9cbddc01e385c45de10108434e692ebcfdd1ffe.json
    3/12:	http://repo.packagist.org/p/provider-2013$443d4993eb01a19e5b9c0ed85763d50a165e58f6daae92c69599b5f1f77cc1df.json
    4/12:	http://repo.packagist.org/p/provider-2014$aff733c7fb02392a130cbbd2061c4aba69284fb12c4a669f1ca6f58662ece6e6.json
    5/12:	http://repo.packagist.org/p/provider-2018-10$6c15f4626e70c51e2c64a5d81bc73b5fd63e52977d8cb4881723228e2b1db361.json
    6/12:	http://repo.packagist.org/p/provider-2015$df12a49db64ac2913f7e5afa571ad73d65352cd9500119b7a94dd3dd0724230a.json
    7/12:	http://repo.packagist.org/p/provider-2018-07$aad9daa43fc6686f71d31d464e5575ad4abfb40832273b0f1909b8f8166928ab.json
    8/12:	http://repo.packagist.org/p/provider-2018$c22051022d2390323549ef645f1857d8e1aa87dcafbb8bcd6ec47bafba730a4c.json
    9/12:	http://repo.packagist.org/p/provider-2016$c0d2fef7c804b9cfcc1b1878b4b57885a55b5fefa2318769a5fc7375e4bf3732.json
    10/12:	http://repo.packagist.org/p/provider-2019-04$213a5ae551370a5d5e09ecd342336891fd96131d188714af40b7ce750b439325.json
    11/12:	http://repo.packagist.org/p/provider-2017$cf3d5431d240c1cbf0b6294530d3b3cbffabb6829b21b0969be0c61b86dafab4.json
    12/12:	http://repo.packagist.org/p/provider-2019-01$0cff58681921696bb23eb2a23508b8c39c0b9502232054c68548f12aae3cee98.json
    Finished: success: 12, skipped: 0, failure: 0, total: 12
Gathering patches for root package.
Removing package drupal/core so that it can be re-installed and re-patched.
  - Removing drupal/core (8.7.3)
Deleting docroot/core - deleted
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing drupal/core (8.7.3): Loading from cache
  - Applying patches for drupal/core
    https://www.drupal.org/files/issues/2019-05-03/delete-form-and-edit-form-links-in-header-for-anonymous-users-2856823-22.patch (get rid of header links that are admin links, https://www.drupal.org/project/drupal/issues/2856823)
    https://www.drupal.org/files/issues/2019-05-02/3039586-22.patch (Exception thrown while performing a schema update. Cannot rename tmp_3a1f98menu_link_content_revision to menu_link_content_revision: table menu_link_content_revision already exists. https://www.drupal.org/project/drupal/issues/3039586#comment-13091985)

Package phpunit/phpunit-mock-objects is abandoned, you should avoid using it. No replacement was suggested.
Writing lock file
Generating autoload files
  - Downloading 1/16: https://cgit.drupalcode.org/drupal/plain/sites/example.settings.local.php
  - Downloading 2/16: https://cgit.drupalcode.org/drupal/plain/sites/example.sites.php
  - Downloading 3/16: https://cgit.drupalcode.org/drupal/plain/sites/default/default.settings.php
  - Downloading 5/16: https://cgit.drupalcode.org/drupal/plain/update.php
  - Downloading 5/16: https://cgit.drupalcode.org/drupal/plain/sites/development.services.yml
  - Downloading 6/16: https://cgit.drupalcode.org/drupal/plain/.htaccess
  - Downloading 7/16: https://cgit.drupalcode.org/drupal/plain/sites/default/default.services.yml
  - Downloading 8/16: https://cgit.drupalcode.org/drupal/plain/robots.txt
  - Downloading 9/16: https://cgit.drupalcode.org/drupal/plain/index.php
  - Downloading 10/16: https://cgit.drupalcode.org/drupal/plain/.ht.router.php
  - Downloading 11/16: https://cgit.drupalcode.org/drupal/plain/web.config
  - Downloading 12/16: https://cgit.drupalcode.org/drupal/plain/.eslintrc.json
  - Downloading 13/16: https://cgit.drupalcode.org/drupal/plain/.gitattributes
  - Downloading 14/16: https://cgit.drupalcode.org/drupal/plain/.eslintignore
  - Downloading 15/16: https://cgit.drupalcode.org/drupal/plain/.csslintrc
  - Downloading 16/16: https://cgit.drupalcode.org/drupal/plain/.editorconfig
> DrupalComposer\DrupalScaffold\Plugin::scaffold
  - Downloading 1/16: https://cgit.drupalcode.org/drupal/plain/web.config
  - Downloading 2/16: https://cgit.drupalcode.org/drupal/plain/sites/example.sites.php
  - Downloading 3/16: https://cgit.drupalcode.org/drupal/plain/update.php
  - Downloading 4/16: https://cgit.drupalcode.org/drupal/plain/.ht.router.php
  - Downloading 5/16: https://cgit.drupalcode.org/drupal/plain/sites/default/default.settings.php
  - Downloading 6/16: https://cgit.drupalcode.org/drupal/plain/sites/example.settings.local.php
  - Downloading 7/16: https://cgit.drupalcode.org/drupal/plain/index.php
  - Downloading 8/16: https://cgit.drupalcode.org/drupal/plain/sites/default/default.services.yml
  - Downloading 9/16: https://cgit.drupalcode.org/drupal/plain/sites/development.services.yml
  - Downloading 10/16: https://cgit.drupalcode.org/drupal/plain/robots.txt
  - Downloading 11/16: https://cgit.drupalcode.org/drupal/plain/.htaccess
  - Downloading 12/16: https://cgit.drupalcode.org/drupal/plain/.eslintignore
  - Downloading 13/16: https://cgit.drupalcode.org/drupal/plain/.gitattributes
  - Downloading 14/16: https://cgit.drupalcode.org/drupal/plain/.editorconfig
  - Downloading 15/16: https://cgit.drupalcode.org/drupal/plain/.csslintrc
  - Downloading 16/16: https://cgit.drupalcode.org/drupal/plain/.eslintrc.json

$ drush updb -n                                                                                                                                                                                                                                                                                                            
 ------------------- ----------------------------------------------- --------------- ----------------------------------------------------------------------------- 
  Module              Update ID                                       Type            Description                                                                  
 ------------------- ----------------------------------------------- --------------- ----------------------------------------------------------------------------- 
  system              8701                                            hook_update_n   Remove the unused 'system.theme.data' from state.                            
  system              8702                                            hook_update_n   Add the 'revision_translation_affected' entity key.                          
  file                8700                                            hook_update_n   Set the 'owner' entity key and update the field.                             
  media               8700                                            hook_update_n   Set the 'owner' entity key and update the field.                             
  media_library       8701                                            hook_update_n   Create the 'media_library' image style.                                      
  media_library       8702                                            hook_update_n   Updates the media library view widget display (contextual) filters.          
  node                8700                                            hook_update_n   Set the 'owner' entity key and update the field.                             
  taxonomy            8701                                            hook_update_n   Add an index on the 'taxonomy_term__parent' field table.                     
  media_library       add_media_library_image_style                   post-update     Create the 'media_library' image style if necessary.                         
  media_library       display_modes                                   post-update     Create and configure Media Library form and view displays for media types.   
  media_library       table_display                                   post-update     Add a table display to the media library view and link gridtable displays.   
  media               enable_standalone_url                           post-update     Keep media items viewable at media{id}.                                      
  menu_link_content   make_menu_link_content_revisionable             post-update     Update custom menu links to be revisionable.                                 
  system              add_expand_all_items_key_in_system_menu_block   post-update     Initialize 'expand_all_items' values to system_menu_block.                   
  system              clear_menu_cache                                post-update     Clear the menu cache.   @see https:www.drupal.orgprojectdrupalissues3044364  
  taxonomy            make_taxonomy_term_revisionable                 post-update     Update taxonomy terms to be revisionable.                                    
  taxonomy            remove_hierarchy_from_vocabularies              post-update     Remove the 'hierarchy' property from vocabularies.                           
  views               exposed_filter_blocks_label_display             post-update     Update exposed filter blocks label display to be disabled.                   
  views               make_placeholders_translatable                  post-update     Rebuild cache to allow placeholder texts to be translatable.                 
 ------------------- ----------------------------------------------- --------------- ----------------------------------------------------------------------------- 
 [notice] Update started: system_update_8701
 [ok] Update completed: system_update_8701
 [notice] Update started: media_library_update_8701
 [ok] Update completed: media_library_update_8701
 [notice] Update started: system_update_8702
 [ok] Update completed: system_update_8702
 [notice] Update started: file_update_8700
 [ok] Update completed: file_update_8700
 [notice] Update started: media_update_8700
 [ok] Update completed: media_update_8700
 [notice] Update started: media_library_update_8702
 [ok] Update completed: media_library_update_8702
 [notice] Update started: node_update_8700
 [ok] Update completed: node_update_8700
 [notice] Update started: taxonomy_update_8701
 [ok] Update completed: taxonomy_update_8701
 [notice] Update started: media_library_post_update_add_media_library_image_style
 [notice] The Media Library (220x220) image style has been created successfully.
 [ok] Update completed: media_library_post_update_add_media_library_image_style
 [notice] Update started: media_library_post_update_display_modes
 [notice] Media Library form and view displays have been created for the following media types: Broker Document, Document, Entity Browser Image, Icons, Image, Partner Agent Document, Podcast Images, Video.
 [ok] Update completed: media_library_post_update_display_modes
 [notice] Update started: media_library_post_update_table_display
 [ok] Update completed: media_library_post_update_table_display
 [notice] Update started: media_post_update_enable_standalone_url
 [ok] Update completed: media_post_update_enable_standalone_url
 [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
 [error]  Exception thrown while performing a schema update. Cannot rename tmp_dc392fmenu_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. 

vuil’s picture

Status: Active » Needs review
FileSize
1.81 KB

Update the #78 patch.

Apply Drupal coding standards and update t() to use $this->t() instead.

vuil’s picture

Status: Needs review » Reviewed & tested by the community
bdanin’s picture

Status: Reviewed & tested by the community » Needs review

Not 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:

drush sql-query "DROP TABLE menu_link_content_revision"; \
drush sql-query "DROP TABLE menu_link_content_field_revision"; \
drush sql-query "DROP TABLE taxonomy_term_revision"; \
drush sql-query "DROP TABLE taxonomy_term_field_revision"; \
drush sql-query "DROP TABLE taxonomy_term_revision__parent"; \
drush sql-query "DROP TABLE taxonomy_term_revision__field_link_address"; \
drush sql-query "DROP TABLE taxonomy_term_revision__field_display_title"; \
drush sql-query "DROP TABLE taxonomy_term_revision__field_post_url";
liber_t’s picture

I 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)

liber_t’s picture

vuil’s picture

Status: Needs review » Reviewed & tested by the community
renatog’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs work
FileSize
57.29 KB
37.63 KB
29.23 KB

I 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,

bwoods’s picture

#81 seemed to have worked for me as well. Thanks!

Znak’s picture

I 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.

vuil’s picture

Status: Needs review » Reviewed & tested by the community
vuil’s picture

renatog’s picture

I didn't test yet but #88 makes sense.

catch’s picture

Status: Reviewed & tested by the community » Needs work

#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?

mh.marouan’s picture

Solution for me : I deleted all tmp table and taxonomy revision table then run update.php.

renatog’s picture

Yeah! 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!

plach’s picture

As @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.

plach’s picture

Issue summary: View changes
Status: Needs work » Postponed (maintainer needs more info)

Updated the IS to help newcomers to figure out what's going on. Setting to needs more info per #92 and #95.

plach’s picture

Issue summary: View changes
plach’s picture

Issue summary: View changes

Added a not about the old_ tables.

gmaka’s picture

I'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

gmaka’s picture

UPDATE,

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.

plach’s picture

Thanks @gmaka, that's helpful!

mmjvb’s picture

Status: Postponed (maintainer needs more info) » Needs work

Disagree 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)

plach’s picture

Issue summary: View changes
Status: Needs work » Postponed (maintainer needs more info)

@mmjvb:

Disagree with #92 and #95. It should be allowed to run the update multiple times. How else are you going to succeed updating!!!

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:

  1. Backup your database
  2. Run the update
  3. On error, restore the database (after deleting every table)
  4. Tweak your codebase or DB content
  5. Go to step 2

The real fix would be to catch these kind of errors as reported in #99/#100 [...]

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.

plach’s picture

Issue summary: View changes

To 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.

nishantkumar155’s picture

i have used 88 patch ,it works but after updb , menu link is not working.

plach’s picture

donaldp’s picture

Deleted 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.

nishantkumar155’s picture

As i used #88 but it was failing i have upaded the patch #88 now menu link are working.

nishantkumar155’s picture

nishantkumar155’s picture

jppo’s picture

Hello,
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

jppo’s picture

A 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

gpap’s picture

[deleted]

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.9 was released on November 6 and is the final full bugfix release for the Drupal 8.7.x series. Drupal 8.7.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.8.0 on December 4, 2019. (Drupal 8.8.0-beta1 is available for testing.)

Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

vuil’s picture

I added my employer only.

AstonVictor’s picture

udhay9321’s picture

I 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.

CH man’s picture

FileSize
2.31 KB
928 bytes
1.14 KB

Hi,
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

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

firewaller’s picture

+1

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
andrimont’s picture

Hello, 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.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

Thank 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!