When trying to create a table that already exists but is empty, recreate the table rather than throwing a DatabaseSchemaObjectExistsException

This isn't a major bug at all, if you install a module, remove it then install it again without uninstalling then that's not going to work.

The exceptions are largely because we switched to PDO. Probably we could handle them better to give a more useful message.

What are the specific steps to reproduce this bug? I've never seen this, and I am able to install all Ctools/Panels modules in D7 with no problem.

It might be possible to make module_enable() clean up after itself better in the case of a catastrophic failure, but we'd need to understand exactly what the failure is first.

I definitely don't think it makes sense to blindly plow ahead and assume everything is OK, though. If you try to create something that already exists, that needs to stop the process (of installing the module in question as well as any modules that depend on it) because you have no idea what the state of the database actually is at that point. Otherwise you risk a site where everything "looks good" but is actually broken underneath, and that would lead to impossible-to-debug problems later on.

- could the existing tables possibly be of an old design and therefore we would need to run updates on them? but can't db code see this and run the updates; most likely the system table entry is still there so we do know what version of schema exists?

The only way Drupal tries to install a module is if the schema version is -1 (indicating that the system believes it to be uninstalled). So I think that means the "actual" schema version would not be available in this case.

- are we trying to force module designers to write code in all .installs to first check if tables exist and then handle this in the .install file? why would we want to replicate this code 200 times on a project?? why not have db code handle this?

Not sure what you mean; Drupal 7 already does handle this. Module authors no longer install their own database tables at all (see http://drupal.org/node/224333#install-schema) so there's no check they need to perform either.

In fact, one way I know you can get the DatabaseSchemaObjectExistsException would be a module that isn't properly updated to D7 and is still trying to install its own schema. But that will fail every time, so it doesn't sound like the case here.

possibly a better approach (although maybe not possible with PDO) would be to simply assume if a table is there it is likely ok (since it pretty much always will be) and then issue warnings that the module install was successful but that the tables already existed and therefore were not re-created; and that proper functional operation should be verified or possibly uninstall the module and reinstall - assuming of course that an uninstall would clean up tables (which i dont think it currently does - didn't help in this case).

Uninstall normally should fix this, but the problem might have been that Drupal believed the module to be already uninstalled.

I don't like the idea of leaving the modules enabled, but it would be nice here to catch the exception, bail out with a friendly message, and tell people that there's leftover data from an older version of the module and give them a chance to uninstall it. Possibly this could be achieved with a different module status that means "broken" (i.e., -2 for the schema version rather than -1, or something like that), which would allow you to go to the uninstall page and at least run some kind of limited uninstallation from there that cleared out the module's database tables.

I try in .install file in fuction hook_install in function
drupal_install_schema('module');

to write
drupal_install_schema('name of table');
, where 'name of table' in 'schema'

In result:

function module_install() {
drupal_install_schema('name of table');
}

And module start to work, and table was created.

I just want to chime in to agree with liquidcms here, as I have experienced a lot of this stuff myself and really having difficulties understanding what the rationale is behind giving a cryptic error message instead of giving the user a choice to try to enable the module anyway.

I have fixed my issues by just going into the db and manually deleting the database tables for the module myself, but that should really not be necessary and is bad usability in my opinion.

This is just a case of "garbage in, garbage out". If you have a database in a weird state, weird things are going to happen. Simply ignoring the garbage (the table already exists, while it should not be here) is only going to make it worse down the line, as weird errors are going to pop-up if the schema of the table is not correct.

The only thing we could do is try to catch this early, and ask the user for the permission to drop and recreate the table (we cannot keep its data, as it is guaranteed to be stale).

Let's study this for 8.x. I'm requalifying this as a feature request because there is no bug here.

I am encountering the same issue

I restored a back up using the "restore and back up" module.
Then I wanted to reenable the internalization module,
but it gives me this error:

"DatabaseSchemaObjectExistsException: Table i18n_string already exists. in DatabaseSchema->createTable() (line 657 of /home/kathrins/public_html/includes/database/schema.inc)."

I understand the table already exists, which makes sense, but I can't seem to get rid of it.
I tried disenabling, uninstalling, clearing caches and reenabling,
but it continues to show this error.

I also tried @liquidcms' suggestion to comment out the following

throw new DatabaseSchemaObjectExistsException(t('Table %name already exists.', array('%name' => $name)));

in /includes/database/schema.inc in the createTable function.

but this doesn't seem the work either ...

I got this while flushing cache on a D7 instance.

Same here when flushing the cache or trying to run update.php on a D7 installation:

DatabaseSchemaObjectExistsException: 
Table <em class="placeholder">field_data_field_body</em> already exists. in DatabaseSchema->createTable() 
(line 657 of ...\includes\database\schema.inc).

I also cannot access admin/structure/features and /admin/modules.

Looked through some of the other related issues and this seems to happen with all kind of modules (core and contributed).

EDIT
Only after deactivating Features using Drush I could get the site working again. So #1272264: Rebuilding features causes FieldException if module is not available might be the right place to follow this issue.

Hi Liquidcms as it better not only to throw out that line, can you give the code for the msg telling the table already existed and which table? and where you put this code? Than at least I can handle it.

Thx!

I'm getting this quite a bit too while working with features. I don't know why it should complain if you ask it to create a table that already exists. It should be happy it doesn't have to create the table :P

Stumbling across this issue quite a lot when using features. Although this doesn't address the core issue, one of the main reasons was that I was using the backup and migrate module to pull the latest version of the production database down to my local development version. When you use the restore function on the backup and migrate module you can be left with a lot of mess in your database as it doesn't drop all tables hence the frequency of seeing this error message. (Would still like to see an elegant solution for the exception issue though!)

I too had this issue when trying to revert features. #20 worked, thanks! Wipe clean the old database before restoring and everything works.

I made a patch for core like #17 and have it in my project's patches directory along with all my contrib patches. This issue happens so much with features for us that it's the only sane way for us to proceed.

I also experienced that #20 helps lots of times

typo

Thank you #17 for posting the solution. I love the solution's elegance.

I'm getting this error a lot when I import a database into a new subdomain in my multisite set up. I'm not sure if multisite will still be an option in D8, but if it is, we who use D7 multisites restore a lot of databases from one subdomain into another, and this error and PDO exception errors are common. Drupal is assuming we don't know what we're doing, but we are doing what we need to.

liquidcms, Thanks for that...I've been struggling with this for Weeks and the solution lies in an obscure reply. I wonder how many others have had this same problem but overlooked this solution in #17. You should be running this show! I repeat my suggestion to Drupal.org administrators/Moderators...EVERY problem topic should require that Moderator post a "Solution" at the TOP of the node, so users will not have to wade through the mire of repeats and unproven suggestions, etc, etc.
I nominate liquidcms for President of Drupal.org...many thanks for your SOLUTION!

Thanks #17 worked for me as well.

Just curious, shouldn't a check like this be standard? Meaning, shouldn't we submit this patch to be part of core?

I would certainly think so, but there seems to be some "political" interests at play here at Drupal.org. Not sure about that, but it seems to me that many here would rather see their names in print, dragging out solutions to generate more dialogue; rather than solving problems for the DrupalUser.

replacing issue summary from #26 which seems to have been made to correct a sentence in the original posters report.

The reason #17 will not make it into core is that it is a workaround rather than a true fix. The reason the thread is still open is that it still needs work, the workaround couldn't go into core because of the possibility of unexpected behaviour or results which can be a nightmare for debugging and very confusing for new users (and experienced ones too). Drupal is throwing an exception because something exists which it doesn't have the capability of handling yet which is the safest thing to do. Yes it is a PITA, yes it needs more work and yes you can use workarounds like the one @liquidcms has been good enough to post up but understand the impact of what you are doing.
@JakeRogers sorry to disappoint you but there is no Dr Evil in charge - if there was I would have liked to shout at him too a few times, it is just regular users giving up time and contributing which anyone can do, the best advice if you don't like things the way they are is to get involved yourself.

This error is easily re-producible if you have a multisite installation with shared core tables. You cannot install the second of the multisite sites because those core tables already exist, and drupal_install_schema() fails. Here's a patch against Drupal 7 core that works for us right now.

sorry, for d7 testing.. I needed to switch versions. I'll switch it back when it's completed.

Untested, but it should work as well in D8.

32: 1551132-drupal-install-schema-shared-tables-D7.patch queued for re-testing.

Now the D7 version has passed, moving this back to D8.

Where is your patch Peter? I agree that having some sort of message would be better. Something like this perhaps?

   foreach ($schema as $name => $table) {
-    db_create_table($name, $table);
+    if (!db_table_exists($name)) {
+      db_create_table($name, $table);
+    } else {
+       watchdog('system', st('Database %name already exists'), array('%name' => $name), 'WATCHDOG_CRITICAL');
+    }
   }

42: schema-table_exists.patch queued for re-testing.

I don't know why you commented out the throw new DatabaseSchemaObjectExistsException line, but that certainly can't go into Core that way. I've rewritten it so that that line is uncommented but that there is a return afterwards. If not it just needs to be removed.

Now for @liquidcms solution (more or less) in D8.

I still think that's too high up for this fix and the Schema object shouldn't do this kind of logic. It should be in db_create_table().

Ok, so this just adds an else with drupal_set_message(t('Table %name already exists.', array('%name' => $name))); if the table already exists.

Actually I think we are still some way off something that is suitable for core, remember we have to cater for all levels of users. If we simply use drupal_set_message, watchdog etc. there are going to be a lot of users who think- 'well I don't know what the message is telling me (in terms of impact on my site), but hey everything looks like it is still working' and carry on as normal but they'd not have the result they were expecting. The reason we were originally throwing an exception is that we are unable to perform the operation we are attempting. I think we may still need to throw an exception but give a more meaningful message that would allow users to actually fix their issue.

if table exists
- check if system entry is there
- - and fix or at least state schema mismatch if there is one
- - if schema is current do nothing
- if entry isn't there delete the table and then continue with the install process (including installing that table)

Yes! ++

(though I wouldn't attempt to fix the schema mismatch, I would just give the error message. At that point there is a mismatch you may have data issues as well and that could get messy fast)

Think that this is still too tied to module install, esp if we are talking about the table_create function. We may be in danger of trying to do too much here. On a code and db level should we be surprised if we try to create a table that already exists and it fails? And should we be writing code to cater for this event? If we do need to write code we should maybe focus on the situations where we are genuinely performing the correct action, (I'd guess in the majority of cases this is not the case i.e. we have junk in our db, or we have done something weird) and not try to cater for this in core functions like table_create.

Subscribing. This issue is currently disrupting our site installs.

If I enable 'comment' I get a scheme error. The module appears to be enabled, but then if I disable it, I cannot uninstall the module in order to clean things up. I am stuck.

Ok - my saga for anyone that might need help or can help further.... as stated just above my 'comment' module got into a state where I could not enable it, but neither could I uninstall it, or at least it was not listed on the uninstall page. #17 above PLUS watching the database for 'field_deleted_data_###' already exists during the uninstall was the solution for me. My database had stray 'field_deleted_data_###' tables laying around. I think these tables are supposed to be removed on cron, but there they were. The problem they create is that when I tried to uninstall 'comment' the uninstall failed because of 'field_deleted_data_###' already exists. Here are the steps to curing my problem. I went through the enable, disable, uninstall 2x with the patch installed, then again without the patch installed to insure everything was operating smoothly again.

1. Run cron
2. REMOVE ANY STRAY 'field_deleted_data_###' TABLES
3. Install patch #17 above
4. Enable the 'comment' module
5. Disable the 'comment' module
6. Uninstall 'comment' module
7. RUN CRON TO REMOVE 'field_deleted_data_###' TABLES
8. Success! Continue...
9. Repeat steps 4-8 one more time. Success! Continue...
10. Remove patch #17
11. Repeat steps 4-8, Success!

In my case I think that early on in my website development I had enabled, then disabled the 'comment' module and then when I went to uninstall the 'comment' module it failed because a 'field_deleted_data_###' table already existed. There could be a serious Drupal bug here if either 1) cron is required to run in order to remove these temporary tables before another uninstall is attempted or 2) there is a race condition on the ### numbering algorithm. Anyway, in my case the uninstall of 'comment' failed, but it was removed from the uninstall list and so I forgot about it until now. Recently I needed to install the 'watcher' module but could not because I was unable to enable the 'comment' module because it was left in an inconsistent state.

My recommendations:
1. A Drupal guru might be advised to look into the bolded theory above.
2. Some smart logic such as #54 above could be very helpful.
3. Perhaps introduce an intermediate page that asks for permission to continue if problems are noticed.

Ok hope this helps, Jeff

Also something MUST be done to fix this because when the 'table already exists' error happens as it inevitably will, the current 'throw error' can make things worse with in the database.

Lots of weird stuff happening with this.

• I'm seeing this in D7 with a whole slew of modules that I'm fairly certain were never enabled to begin with running on a fresh database.
• As other people have noted, some of the modules it claims to already have a table for does not have a way to uninstall.
• Sometimes I've even noticed it throw the error for an existing table when that module is not currently being enabled.

I'm not really sure how that's possible given the circumstances of this error. I clear the cache regularly. The modules do eventually become enabled through attempting to enable multiple times.

admin/structure/content_migrate
Changed field type: The 'field_foto' field type will be changed from 'filefield' to 'image'.

Error message

Error creating field field_foto
exception 'DatabaseSchemaObjectExistsException' with message 'Table field_data_field_foto already exists.' in includes/database/schema.inc:657 Stack trace:

#0 /includes/database/database.inc(2720): DatabaseSchema->createTable('field_data_fiel...', Array)
#1 modules/field/modules/field_sql_storage/field_sql_storage.module(259): db_create_table('field_data_fiel...', Array)
#2 [internal function]: field_sql_storage_field_storage_create_field(Array) #3 /includes/module.inc(866): call_user_func_array('field_sql_stora...', Array)
#4 modules/field/field.crud.inc(180): module_invoke('field_sql_stora...', 'field_storage_c...', Array)
#5 sites/all/modules/cck/modules/content_migrate/includes/content_migrate.admin.inc(246): field_create_field(Array)
#6 [internal function]: _content_migrate_batch_process_create_fields('field_foto', Array)
#7 /includes/batch.inc(284): call_user_func_array('_content_migrat...', Array)
#8 /includes/batch.inc(161): _batch_process()
#9 /includes/batch.inc(80): _batch_do()
#10 /modules/system/system.admin.inc(2379): _batch_page()
#11 [internal function]: system_batch_page()
#12 includes/menu.inc(517): call_user_func_array('system_batch_pa...', Array)
#13 index.php(21): menu_execute_active_handler()
#14 {main}

Um. We should not move this to a different project until the Drupal Core issue is resolved? If you need an issue for a different project, please file a different issue... or else explain why it should not be a Drupal Core issue any more.

The current version of 8.0.x-dev already checks if the table exists before creating it.

Well the bug most likely still exists in 7.x.

In deed it does and happens regularly with Features Modules because of cache clearing. Which patch is deemed the best to use for now on D7?

I've got this when I've tried to upgrade a D6 site to D7. The site had a custom module (that I had to port to D7) with a custom database table. Now when I've tried to enable the module, the install has failed because the database table was there already. I could only enable the module with temporarily commenting out the table definition in hook_schema(). (By the way, similar things happen if you try to use a db_add_field() in hook_install() for adding a field which already exists.)

The current version of 8.0.x-dev already checks if the table exists before creating it.

Looking at drupal_install_schema() I don't see where it does that at all.

And certainly if I test manually by adding drupal_install_schema('forum') to the Forum module's hook_install() implementation in Drupal 8, everything explodes with a Drupal\Core\Database\SchemaObjectExistsException when I try to enable the module.

Here's the D7 version of #51.

My database got into a state where field_data_field_whatever already exists, but the field wasn't listed on the manage fields form, and there was an error when I tried to create the field as new. With the patch applied I'm able to create the field anyway.

The Drupal 7 patch failed testing because it tries to apply it against Drupal 8.
I updated the Drupal 7 patch file name so it puts the comment number before the Drupal version, according to https://www.drupal.org/patch/submit

Apparently the naming isn't enough to make it run against Drupal 7. Maybe the version of this ticket needs to change. I'm not going to fiddle with that.

About the patch itself; I would not accept it because it introduces an inconsistency with the rest of the methods in that file because it does not throw an error.
I would rather provide a new method createTableIfNotExists() that creates a table, unless it already exists, but doesn't throw an exception or logs a message is a table already existed. But then, what code is going to call that new method? Just thinking out loud.

Besides, I'm also having a look at #1343330: Field creation error needs correct cleanup which suggests a different approach.

@PieterDC You can change the issue version and post a patch with status "Needs review" then change the issue version back.

Oh, and there are some "testing only -- ignore issues" around you can use to simply post a patch for testing.

#47
Fail on Commerce Kickstart 2.33 on New Install

I think, this is a great bug that comes with a security update on the core.
In old version on my sites, i have no problems.

In versions greater then 7.41 or near earlier ther was no problems with Commerce Kickstart.
But the older versions of the Core and some modules are no php7 compatible.

Php7 is the next great perfomancestep in the buildfuture.

Builders, please consider that.

I'm working on an adaptation of the CK-style from OT5 to AT Commerce.
But i use for this the "costum css tool" > I dont like change the original corefiles... > Hackatacks on WP in the year 13, 14 and 15 in the german Help-Forum Webmasterzentrale by google...

The patch in #72 seems to resolve this problem on D7 for me.

LiquidCMS' comment #11 did the trick for me.

Encountered this issue when reverting features after a git branch checkout. Commented out the line throw new DatabaseSchemaObjectExistsException(t('Table @name already exists.', array('@name' => $name)));, reverted features and finally uncommented the line again.

Patch #72 did worked for me too. Thanks!

Confirming patch #72 fixed D7 issue for me as well.

#72 solved my perpetual errors from features that have been copied between servers. hopefully this gets into core soon.

#72 works great, let's get this committed in 7.53

As said in #1551132-74: When trying to create a table that already exists but is empty, recreate the table rather than throwing a DatabaseSchemaObjectExistsException and previously by others in earlier comments, the patch from #1551132-72: When trying to create a table that already exists but is empty, recreate the table rather than throwing a DatabaseSchemaObjectExistsException is not good enough to be committed. Ignoring errors is bad practice.

Instead I suggest a patch that adds a special case: if a table already exists and is empty then drop it before trying to create it. (This helped in most of our use cases.)

To me that's a step in the good direction. We're still missing test coverage. And ideally - as suggested by the issue creator - the core schema system would be smart enough to upgrade the table structure to the wanted structure, if needed, and even if it contains data. https://www.drupal.org/project/schema could help with

Schema comparison: the module compares the live database structure with the schema structure declared by all enabled modules, reporting on any missing or incorrect tables.

I changed the Drupal version of this issue from Drupal 8 to Drupal 7 so the patch can be tested by the test bots. Changed issue tag "Needs backport to D7" to "Needs forward port to D8" accordingly.

#32 didn't worked for me, but #87 works like a charm. @PieterDC great job! I agree with suggested special case:

if a table already exists and is empty then drop it before trying to create it. (This helped in most of our use cases.)

#87 worked for me. Thanks

This is a great discussion, and explains what is happening to me when trying to install some commerce submodules, on a dirty database that has modules not uninstalled correctly.
I want to bring up here another related issue, but the opposite: Uninstall

When trying to uninsnstall a module that drops table that not exists, it throws the PDO execptio, stops the uninstall process execution and consequently do not complete the 100% of the table removal, and related queries. Probably sometimes, this issue may be the cause of the main error of this discussion. (because is you try to re-install the module again, you will find the initial 'table already exists error'

This is an example of my usecase:

"exception 'PDOException' with message 'SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mydb.field_data_discount_usage_per_person' doesn't exist' in            [error]
/public/includes/database/database.inc:2227 "

A workaround that worked for my was adding couple of checks on field_sql_storage.module:

+++ b/public/modules/field/modules/field_sql_storage/field_sql_storage.module
@@ -370,6 +370,9 @@ function field_sql_storage_field_storage_delete_field($field) {
   $field['deleted'] = 0;
   $table = _field_sql_storage_tablename($field);
   $revision_table = _field_sql_storage_revision_tablename($field);
+  if (!db_table_exists($table) || !db_table_exists($revision_table)){
+      return ;
+  }

And an add " if (db_table_exists($table_name)) " around the update queries.

#87 works for me on Drupal 7.56! I like the solution that checks if the table is empty and drops it if it is. This also fixes the exceptions that sometimes occurs with reverting Features.

Guess we can mark this as tested and reviewed? Code looks clean to me.

This new approach is interesting and seems worth considering. I think in most cases this behavior is what we want, although can also imagine some scenarios where it isn't (e.g. two different modules trying to define a table with the same name; in that case you're going to get errors either way at some point down the line, so it's better to get them up front).

However, it still needs to be considered for Drupal 8 first.

It also looks like the patch is using functions that shouldn't be called from here:

1. Instead of db_select() I'm pretty sure you want something more like $this->connection->select() - to ensure that the correct database is being queried. (That is how the rest of the database API does it.)
2. Calling watchdog() also seems problematic since that's a very high-level function (that invokes hooks, etc) whereas this is a low-level function that is calling it. Is logging this really necessary at all? I'm not sure it provides much useful information to the site owner. One option to consider would be to use the function return value to communicate this information instead, just in case the calling code wants to know (sort of similar to what https://api.drupal.org/api/drupal/includes%21database%21mysql%21schema.i... does). I'm not sure if that's a good idea or not.

#87 works for me on Drupal 7.59. Thank you.

I had originally UNINSTALLed (since you have no choice in 8.x) the Shortcut module and then came back to install it and got this error message. It needs to be fixed.

This has resulted in a site down hard.

Adjusting the patch as it is no longer applies due to changes introduced in #2848822: Replace all calls to db_create_table, which is deprecated, #2848817: Replace all calls to db_table_exists, which is deprecated. and #2935256: Remove all usages of drupal_get_message and drupal_set_message in modules.

I agree this needs to be fixed.

Is there a legal way to do this in an extraneous module?

  public function createTable($name, $table) {
    if ($this->tableExists($name)) {
      // throw new DatabaseSchemaObjectExistsException(t('Table @name already exists.', array('@name' => $name)));
      $this->dropTable($name);
      watchdog('database', 'Dropped already existing table @name before recreating it.', array('@name' => $name));
    }
    $statements = $this->createTableSql($name, $table);

etc

There doesn't seem to be but maybe I'm missing something?

If I want to change the install process so that the system drops the tables outright (data or not, be damned, just recreate the tables!) is there some way I can do this? What would I hook into? What would I replace?

I discovered something in #3043907-3: DatabaseCacheBackend::ensureBinExists() does not properly handle exceptions. If I am correct about that it may interest some people following this issue.

The thing I love about Drupal is I'm still coming back to this thread 7 years later, and it's still going strong...

As long as it's not committed to D8, I can't push it forward in D7, sorry :(

I think this is more fixable now that #3043907: DatabaseCacheBackend::ensureBinExists() does not properly handle exceptions is in.

Hi, thanks for patch #99! It is working great!
Greetings, Martijn

Patch #87 tested successfully for Drupal 7.

-1 The current way that the createTable() method works is that an exception is thrown when there is already a table with the new table name. Changing that would result is a BC break. And that is something we cannot do. Also deleting the existing table could result in a loss of data.

The current suggested patch does not do what the IS says.

As a result of the previous comment, back to needs work.

@daffie

"Changing that would result is a BC break. And that is something we cannot do. Also deleting the existing table could result in a loss of data."
What is BC?
Also, the patch checks to see if the table is empty before removing it.

"The current suggested patch does not do what the IS says."
What is IS?
The initial submission asks a bunch of questions and is frustrated.
How can we move this forward to get the change committed in code?

I rerolled the patch of #87 for Drupal 7.x-1.x and the latest stable Drupal core 7.72 versions.

I rerolled the patch #99 for Drupal core 8.8.10

Added tests for 9.2.x branch.

I rerolled the patch of #113 for Drupal 7.x-1.x and the latest stable Drupal core 7.83 version.

I created a patch for 9.3.x, applying the strategy from comment #118 directly to the createTable() method in Schema.php. This move is based on drupal_install_schema() being deprecated in 9.2.0: https://www.drupal.org/node/2970993

Tested patch from #115 on 9.2 and it works well.

+++ b/core/lib/Drupal/Core/Database/Schema.php
@@ -611,7 +611,13 @@ protected function introspectIndexSchema($table) {
+      if ($this->connection->select($name)->countQuery()->execute()->fetchField() == 0) {
+        $this->dropTable($name);
+        \Drupal::messenger()->addStatus(t('Dropped empty, existing table %name before recreating it.', ['%name' => $name]));
+      }

This shouldn't use messenger. I'm not sure if it's a good idea to do it at all, but if so and we want to have a message, it should use trigger_error(). Also needs test coverage.

Made changes as per comment #123, but still, need work for the test.

Hi, we are using the patch from #120 and it introduces a lot of problems when you have more than one PHP workers, as the function is not atomic anymore. This might work in a single-threaded install but will fail with hard to debug concurrency issues when called by code on every request. The purge module for example tries to create a table if it does not exist prior which leads to a never ending series of table creation and -dropping as one function call form Worker A is intertwined with a function call from Worker B.

This happens under heavy load only, but still the offending code should be guarded by a lock.

I can confirm that #115 solved the problem on Drupal core 8.9.20 (silver lining while upgrading a very out of date site).