Status

()

The Bugzilla bug-tracking system.Note: This is not the place to request configuration, permission, or account changes to this installation of Bugzilla (bugzilla.mozilla.org). File such changes under the appropriate component in the bugzilla.mozilla.org product.

Comment on attachment 112501[details][diff][review]
patch v1
This has a race condidion between the delete and the insert.
If I have two transactions, and both try to add an entry which doesn't exist,
then both will delete nothing, then try to insert, which will fail the
duplicate key tests.
You can either:
a) LOCK the table first; or
b) UPDATE
<if no rows updated>
LOCK
DELETE
INSERT
UNLOCK
<end if>
IOW, have a fast-path, and a slow path.
I'm not sure if thats worth it here, though, since people don't replace
namdqueries that often, and it is a quick operation. Not to mention that the
INSERT is a table locking operation anyway for mysql...

one of them was already halfway there, someone just forgot to remove the
"REPLACE INTO", which never would have gotten called unless it was an INSERT
anyway. Changes the second one to just an INSERT, and adds the if/then to the
first one.

A more performant way to deal with this is to deal with both error codes you can
get:
UPDATE
IF no rows THEN
INSERT
IF duplicate key THEN
UPDATE
This removes the need to do ugly things like lock tables. It's also probably the
most database agnostic way to do this, since Oracle and PostgreSQL handle
locking comelpetely differently than other databases.
Note that the drawback to this is that it doesn't protect against deletes.

New patch that I have also in my PostgreSQL patch. I am trying to break things
out into smaller chunks for easier commiting of the PostgreSQL changes later.
This patch also adds a couple of other fixes for query.cgi and checksetup.pl.
Was a descision ever made whether just performing a LOCK around this section is
the way to go or to do a DELETE/INSERT pair?