Do I need serializable for this query? -- Part 2

This is part 2 of my "serializable" question from earlier. Thanks to
everyone who answered the first part. (Hopefully there will be no part 3)

When a user adds a record, I update a table with totals. But when a
user deletes data, I subtract the totals. That presents a more
interesting situation since it is theoretically possible to add a record
and delete one at the same time:

For simplicity sake, the two tables are something like:
item(itemid int, data...)
history(itemid int, versionid int, data...)

-- This deletes the item and all the history records for the item
CREATE FUNCTION DeleteItem(IN _UserID int,
IN _ItemID int)
RETURNS void AS $$
DECLARE
mycount int;
total bigint;
BEGIN
-- Cotal and total of data to be deleted
SELECT
COUNT(*), COALESCE(SUM(clientsize),0)
INTO
mycount,total
FROM
history
WHERE
userid= $1 AND itemid=$2;

-- Potential problem point #1

-- Call the stored proc to update the count and total
-- This is the one from my last email
PERFORM sbp_UpdateTotals($1,-mycount,-total);

-- Potential problem point #2

-- Delete the records
DELETE FROM history WHERE userid = $1 AND itemid=$2;
DELETE FROM items WHERE userid = $1 AND itemid=$2;
END
$$ LANGUAGE 'plpgsql' VOLATILE;

Suppose the user adds another record to the history table with the same
itemid as the one being deleted. If they do this at one of the two
"problem points" then that history record will be deleted, but it will
not be subtracted from the totals. Am I understanding this properly?

In my system, this is highly unlikely, and probably not even something
we care about very much. But I still want to know what to do. It seems
to me I could a few things to fix this:

1) Make this serializable
- I'm not even sure this will help, since adding a new history record
won't change any records that this touches. Would PostgreSQL even
realize that adding a history record would have changed the results of
the select?
2) Table lock
3) Make the first select statement store the PK(itemid,versionid) of the
history records and then only delete those records at the end.
4) Somehow calculate the count and total during the delete statement
5) Compare the # of records deleted with the # of records selected and
throw/rollback if they mismatch.

I'm curious which one I should do, and if my solutions are all valid.

Also, I'm under the impression that I don't need to do any sort of
begin/end transaction stuff in here, since PostgreSql does that
implicitly with any stored procedure. Is that correct?

Thanks to anyone who can assist.

Florian G. Pflug wrote:
> William Garrison wrote:
>> I have a table that keeps running totals. It is possible that this
>> would get called twice simultaneously for the same UserID. Do I need
>> to put this in a serializable transaction? Since this gets called
>> often, could it be a performance problem if I make it serializable?
>>
>> CREATE FUNCTION UpdateTotals(IN UserID int,
>> IN AddToCount int,
>> IN AddToSize bigint)
>> RETURNS void AS $$
>> BEGIN
>> UPDATE
>> Totals
>> SET
>> TotalSize = TotalSize + $2,
>> TotalCount = TotalCount + $3
>> WHERE
>> UserID = $1;
>> END IF;
>> END
>> $$ LANGUAGE 'plpgsql' VOLATILE;
>
> Where is that stray "END IF;" comming from?
> Anyway, this should be safe, and work even more
> reliably in read-committed mode than in serializable
> mode. In serializeable mode, if the Total of the same
> user is updated by two transactions simultanously,
> you'll get a SerializationError. Read-Committed mode
> OTOH will make sure that it uses the latest version of
> the tuple for calculating the new values.
>
> Usually, you need serializable mode if you do updates
> based on the results of previous selects.
>
> greetings, Florian Pflug
>