PDOException: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist

Similar error here:

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist: ROLLBACK TO SAVEPOINT savepoint_1; Array ( ) in CommerceOrderEntityController->save() (line 104 of /sites/all/modules/commerce/modules/order/includes/commerce_order.controller.inc).

closed as duplicate: #1825628: PDOException 1305 SAVEPOINT savepoint_1 does not exist -- when trying to add content type

Seems #1007830: Nested transactions throw exceptions when they got out of scope didnt totally fixed this?

You closed my other ticket (referenced above) as a duplicate of this one. But you also filed this one under Drupal version 8. My site runs 7. Is the resolution to this issue going to help Drupal 7?

Its resolution will have to get through drupal 8 first and then backported to drupal 7

Respectfully, if this is a major bug (it is for us) in 7, isn't it important to get treated as such? I'm concerned that it will just be on a long list in developing 8, since 8 is a long way to production status, whereas in a live 7 site, it's a much more immediate priority -- for example, we can't even create new content types, which is critical for our site right now.

I didnt mention that this will have to wait until drupal 8 is released.
Just that this fix will have to committed to drupal 8 repository and then drupal 7..that helps the two branches being in sync and ensures all bugs fixed in drupal 7 are fixed in drupal 8 as well.

I came here because in apachesolr_entity_update() I got the same error message from the ->execute() line at the end of the function.

In my case it's not repeatable though. I'm creating a million nodes on a daily basis, and I've only seen this message a single time. (It could have happened more often and I haven't noticed though).

I've hacked my core with the following patch to get some better debug data out. But after I applied it the error stopped reproducing >_<. Uploading in here so others with the issue can try applying it as well.

We are also seeing this error several times a day.

So, issue summary - this bug appears often, and 2 months in, no-one has any idea what is causing it. Correct me if wrong.

For what it's worth, I usually see this error when field-related actions (e.g. deleting nodes) happen concurrently.

If you're getting this error, please post your MySQL version.

http://bugs.mysql.com/bug.php?id=38187 looks like a possible issue if you're running 5.0.*

MySQL 5.0.95 for me, so one sample in, that's a possibility. Looks like it was 5.1.33 that the posted bug was fixed in.

Marked #1792918: SAVEPOINT error in file_usage_add as duplicate of this issue.

Getting a similar error:

Sep 17 07:32:34 ip-10-136-121-12 drupal: http://www.site.com|1379403122|node|127.0.0.1|http://www.site.com/sites/all/modules/contrib/elysia_cron/cron.php?cron_key=xxx||0||PDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist: ROLLBACK TO SAVEPOINT savepoint_1; Array#012(#012)#012 in EntityAPIController->save() (line 486 of /sites/all/modules/contrib/entity/includes/entity.controller.inc).

MySQL is newer than #13 is hoping for:

$ mysql --version
mysql  Ver 14.14 Distrib 5.5.32, for debian-linux-gnu (x86_64) using readline 6.2

Have a similar error message:

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist: ROLLBACK TO SAVEPOINT savepoint_1; Array ( ) in node_save() (line 1198 of /var/www/htdocs/.../modules/node/node.module).

The error doesn't appear if I change the storage engine of the table file_usage from InnoDB to MyISAM

Same problem. Happens for me during feeds import, with apachesolr running on Drush.

Array() in apachesolr_entity_update() (line 1832 of  sites/all/modules/contrib/apachesolr/apachesolr.module).
WD node: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist: ROLLBACK TO SAVEPOINT savepoint_1;       

MySQL 5.1, PHP 5.3.

@dendie that would probably be because MyISAM doesn't support transactions.

This error occurs for me when a order is created.
The server is running mysql version mysql 14.14 Distrib 5.5.34.
Drupal 7.23
PHP 5.3.10

I still experience this issue too. This indeed seems to happen during in concurrency scenarios.

Code like this:

try {
  $tx = db_transaction();
  ... // Dobusiness stuff
} catch (Exception $e) {
  if (isset($tx)) {
    $tx->rollback();
  }
  throw $e;
}

Will sadly loose the current exception when another happens during rollback.

While a better algorithm such as:

$tx = null;
try {
  $tx = db_transaction();
  ... // Do business stuff
  unset($tx); // Explicit commit
} catch (Exception $e) {
  if ($tx) {
    try {
      $tx->rollback();
    } catch (Exception $e2) {}
  }
  throw $e;
}

Will catch the real business error and tell us what we need to know.

Which makes me think that the SQLSTATE[42000] ... 1305 SAVEPOINT ... error we all experience are actually hiding the real exception behing, and for some reason, probably a poorly coded algorithm somewhere or a MySQL bug, we cannot solve the real cause, which in concurrency scenarios could be a concurrent transaction deadlock timeout reached instead.

Meanwhile, I did a very simple patch that should unhide the original exception that did trigger the rollback by using the attached patch.

The attached patch was made using SVN diff so please apply it manually and not with git. Please also note it has been made on a 7.15 core.

Oups wrong patch attached.

im also getting the issue, currently its occuring when uploading files, and changing the state of checkboxes at the same time, while trying to update a node from a custom form.

Drupal 7.32-dev

#25 should be at needs review.

Can anyone reproduce this in 8.x? "bugs should be fixed in HEAD first" but we don't have any evidence that it exists in 8.x

Rerolling patch from comment 25:

I was receiving this error when using VBO on large numbers of items. The error would cause the batch process to stop. While I don't understand the root cause of the error, the above patch #32 does appear to allow my VBO batches to process without failing.

Thank you.

Seen in Drupal 7.44 & MySQL 5.5.52-0ubuntu0.14.04.1-log (Ubuntu)

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist: ROLLBACK TO SAVEPOINT savepoint_1; Array ( ) in EntityAPIController->save() (line 481 of .../entity/includes/entity.controller.inc).

followed by

SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist

I have applied patch #32 and will monitor for any re-occurrence - thanks pounard & lhridley!

I am able to reproduce in D8 with patches from #933004: Test that all form elements have a title for accessibility, wherein I do a lot of entity creation and some exception catching.

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist: ROLLBACK TO SAVEPOINT savepoint_1; Array ( ) in EntityAPIController->save() (line 481 of [snip]/entity.controller.inc).

When trying to create a user account.

Recently had this issue too. On a commerce product (core 8.4.4, commerce 2.3). Seems this occurs simply by visiting the page.

AH01071: Got error 'PHP message: Uncaught PHP Exception Drupal\\Core\\Entity\\EntityStorageException: "SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist: ROLLBACK TO SAVEPOINT savepoint_1; Array\n(\n)\n" at /mysite/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php line 805\n'

Same issue, Drupal 8.5.2, MySQL 5.7.17

Attempt to port the patch from #32 to D8

+++ b/core/lib/Drupal/Core/Database/Connection.php
@@ -1111,7 +1111,13 @@ public function rollBack($savepoint_name = 'drupal_transaction') {
+        } catch (PDOException $e) {

This should be } catch (\PDOException $e) {, missing \ before PDOException

Made that specific change and re rolling that patch against 8.6.x

Fixing CS issue and removing other line

Hi All,

I tried the patch #45, it seems to me that the issue still exists.

I'm facing this issue while saving content randomly on Drupal 8.5. Does anyone else still face the same issue?

Thanks for your help!
Adi

Need work as patch provided in #45 doesn't solve the issue. It's still occurring for content type with Paragraph fields. Thanks

I've applied patch #32 but still get this error

PDOException: SQLSTATE[HY000]: General error: user-supplied statement does not accept constructor arguments: ROLLBACK TO SAVEPOINT savepoint_1; Array ( ) in EntityAPIController->save() (line 481 of /sites/all/modules/entity/includes/entity.controller.inc).

I have

Drupal 7.65
PHP 7.2.15
mysql 5.7.25

Specific modules used when this happens:
video
paragraphs

this happened for us while updating paragraph update version 8018, still facing the same.

Patch # 32 has fixed my Drupal 7 error. I'm testing a load test with 200 concurrent users to create a node programmatically through an API request. Almost 3 or 5 bugs occur before patching. Once patched, the entire request was successfully created in the database.

when trying to save node in hook_comment_insert -> the issue is still there in core: 8.9

To anyone hitting this - we were doing some load testing on a server and hit the "savepoint_1" error hard. It wasn't consistent, but it was reproducible under load.

One of the problems diagnosing savepoint_1 appears to be that SqlContentEntityStorage::save() calls $transaction->rollBack(); as part of an Exception catch. $transaction->rollBack() runs a number of commands that come around and run SqlContentEntityStorage::save() AGAIN. This time around, the savepoint_1 error is hit and the system dies and logs savepoint_1.

savepoint_1 is likely a red herring - you need to figure out what the original exception was that triggers the rollback in the first place.

We fixed this by swapping the order of the rollback and watchdog_exception, changing this:

    catch (\Exception $e) {
      $transaction->rollBack();
      watchdog_exception($this->entityTypeId, $e);
      throw new EntityStorageException($e->getMessage(), $e->getCode(), $e);
    }

to this:

    catch (\Exception $e) {
      watchdog_exception($this->entityTypeId, $e);
      $transaction->rollBack();
      throw new EntityStorageException($e->getMessage(), $e->getCode(), $e);
    }

For us, this looks like it's a SQL Deadlock issue, as described in #2833539: SQLSTATE[40001]: Serialization failure: 1213 Deadlock

I'm not sure I'd advocate for a patch that swaps the order of watchdog_exception() and rollBack(), as watchdog_exception has to log to the database as well, but if you're trying to crack this problem, look here first.

TL;DR: If you see a savepoint_1 error, it's likely masking some other error that's getting lost in the catch block of SqlContentEntityStorage::save().

We also had this issue in combination with #2833539: SQLSTATE[40001]: Serialization failure: 1213 Deadlock
and created the 1803886-switch-rollback-and-exception-logging.patch.

Hi, I made a patch for Drupal 9.3.x based on the patch of comment #55 because the source code in Drupal 9.3.x is a little bit different.

Rerolled patch for 9.4.x in MR !3105.

Re-roll for 10.1.x.

https://git.drupalcode.org/project/drupal/-/merge_requests/5283/diffs

As pointed out at #54, this patch is absolutely not a viable solution. Logging exception before rolling back transaction basically means that the exception won't be logged.