Duplicate entry ... for key 1 query: INSERT INTO i18n_strings ... i18nstrings.module on line 247

I have had the same issue.. this definitly should have a line in the documentation, never would have suspected that emptying that table might fix it... but this obviously would drop any customized stings IIUC.. should there not be a different fix for this?
And what exactly is going on, the troubling field is deleted in the previous line but then it complains about a duplicate entry?

AHA... it's a
race condition

that is occuring here.... mmhhh .... so there's no quick fix other than regularily running
DELETE FROM `watchdog` WHERE `variables` REGEXP 'Duplicate.*INSERT.*i18n'...

Not for the handbook, this is a bug, to do more research...

it is not a bug, it happens when the same page is accessed by multiple users at the same time. To prevent this from happening, the table has to be locked. I believe this is planned for D7.

True, it's some race condition, which seems to be all around Drupal.

Anyway, implemented some workaround, this should avoid more error logs

I don't understand why this problem can't be fixed. If it's a race condition (which I agree, this does look like the case), the solution is to fix the race condition, not clear the table! This simple patch removes the race condition and doesn't increase the number queries. Instead of doing a DELETE/INSERT it does a SELECT/UPDATE. This problem was flooding our site's watchdog with thousands of entries per hour.

the patch didn't apply to the head version but it was not overly complicated to do it manually. It works and looks like the right way to do it, good job quicksketch. (Cool, now i know how to fix an SQL race condition ;)

Alternate version of the patch based on the solution used by cache_set and variable_get in d6

Even better, one less SQL query. You're the dudes folks. Here's the patch rerolled for HEAD.

Agreed, this is the correct fix.

There's no need for the @ symbol before the call to db_query(), this could obscure problems in the future if the query does cause errors, they shouldn't be suppressed. Was there are reason for adding this neclimdul?

neclimdul was following the code in variable_set() and cache_set(), which both use the @.

This was introduced in #55516: Remove database locking.

Seems like David Strauss added the @ in #130 though the reason was never stated. I'll ask him about this need, but my guess is that it is unwarranted, just the result of following a pattern that existed before the locking was fixed (perhaps the @ was necessary at one point if a race condition were causing errors).

Well whatever the @ means, the fix is ready to be committed.

it suppresses errors

http://www.php.net/manual/en/language.operators.errorcontrol.php

I agree we can go ahead and commit this. When I satisfy my curiosity about the @ sign, I'll make a patch for core first if it can be safely removed (my feeling is that it can), though as nedjo points out, all this code is gone anyway in Drupal 7 thanks to the new database layer.

This issue indeed is worth fixing; but it suggests incorrect calls elsewhere to the tt() function.

tt() can be called in two ways--to add or update a string to be translated or to fetch an existing translation (if there is one).

The fact that we're getting high volume write operations suggests that insert/update operations are being called inappropriately.

It would help to know just what queries are failing, so we can track these issues to their source.

I had a look around and found this issue in i18nmenu: #339057: Performance: menu translations continuously updated, which was one instance of updating instead of fetching. The patch there may help reduce these errors.

All of which suggests that we shouldn't suppress error messages--they're indicators for where we need to fix other code. So let's leave out the @.

Likely we are indeed getting race condition errors. But looking again at the original error message above, it seems noteworthy that the particular string being inserted is 0. A possible cause is:

* for whatever reason, we have a 0 being passed to tt().
* the first time this happens, a record is created
* the next and all subsequent times, the query to find an existing translation returns 0, which is interpreted as not finding a translation, so a new insert is attempted
* the new insert fails, because there is an existing record.

Probably we should bail early when an empty value is passed to tt(). We may also need handling of this case elsewhere.

I have a feeling the @ might be to help with replication, but that's only half-remembered. Will be interested to see what the answer actually is.

I committed a version of the patch without @ and left a code comment.

Setting to needs more info pending more information on the @ question.

I looked further at the code and concluded we can't suppress empty values, since they're used to trigger deletes.

Thanks nedjo, this looks much better now. Also committed a related patch which may avoid unneeded updates, #339057: Performance: menu translations continuously updated

About the @db_query(), I've added it back, reasons commented on the code. Otherwise we'd need an extra select statement to check if the value is already there. This will allow people to use the module while we (developers) can look for better options here.

The weird values passed around may come from other modules using i18nstrings, for further investigation....

Marked #369734: user warning: Duplicate entry '4478' for key 1 query: INSERT INTO i18n_strings (lid, type, objectid, property) as a duplicate.

m having similar problem on my website