Jasper Bryant-Greene wrote: > On Tue, Jul 24, 2007 at 02:46:11PM -0700, David Jonas wrote: >> Jasper Bryant-Greene wrote: >>> On Tue, Jul 24, 2007 at 02:09:23PM -0700, David Jonas wrote: >>>> < SELECT current FROM quota WHERE ... >>>>> 513965019 >>>> < BEGIN >>>> < INSERT INTO quota (current, ... >>>> < COMMIT >>>>> ?? (error_r appears to be (null)) >>> Unrelated to the original post, but the above would appear to be a bug to >>> me. >>> >>> Because the SELECT is done before the transaction starts, the value in the >>> INSERT which is based on the SELECT may no longer be consistent with the >>> actual value in that table. >> I don't think it uses the value. The INSERT statement that comes next >> does an UPDATE if the key exists. The value represented as 0 here is the >> change in quota value: >> >> INSERT INTO quota (current, path, username) VALUES (0, 'quota/storage', >> '[EMAIL PROTECTED]') ON DUPLICATE KEY UPDATE current = current + 0; >> >> So it's only added to or inserted, never changed then replaced. > > OK, so absolutely nothing about the INSERT (including whether or not it is > performed) depends on anything about the result from the SELECT?
I won't pretend to know for sure, but as far as I can tell, no. I never poked around to find out why the SELECT is done. I'm guessing it was done to see if the quota needed to be recalculated (negative values cause a recalculation, according to the comments). > Jasper
