* Albe Laurenz:
> The original question asked was "how can I tell an error that is caused
> by incomplete isolation from another error?"
>
> If you have a code segment like
>SELECT COUNT(id) INTO i2 FROM a WHERE id = i;
>IF i2 = 0 THEN
> INSERT INTO a (id) VALUES (i);
>END IF;
>
* Craig Ringer:
> The test program, attached, demonstrates what I should've known in the
> first place. In SERIALIZABLE isolation, the above is *guaranteed* to
> fail every time there's conflict, because concurrent transactions cannot
> see changes committed by the others. So is a SELECT test then
Craig Ringer wrote:
> > The drawback is that some of the side effects of the INSERT occur
> > before the constraint check fails, so it seems to me that I still need
> > to perform the select.
>
> If you really can't afford the INSERT side effects and can't redesign
> your code to be tolerant of th
On Thu, 2009-07-16 at 14:13 +, Florian Weimer wrote:
> The drawback is that some of the side effects of the INSERT occur
> before the constraint check fails, so it seems to me that I still need
> to perform the select.
I was about to foolishly suggest:
Instead of:
SELECT 1 FROM x WHERE a = 4
* Albe Laurenz:
>SELECT COUNT(id) INTO i2 FROM a WHERE id = i;
>IF i2 = 0 THEN
> /* This INSERT will never throw an exception if the
> transactions are truly serialized */
> INSERT INTO a (id) VALUES (i);
> RETURN TRUE;
>ELSE
> RETURN FALSE;
>END IF
Florian Weimer wrote:
> SERIALIZABLE isolation level doesn't really conform to the spec
> because it doesn't deal with phantoms. The only case I've come across
> where this actually matters is when you're implementing some sort of
> "insert into table if not yet present" operation. This will typi
SERIALIZABLE isolation level doesn't really conform to the spec
because it doesn't deal with phantoms. The only case I've come across
where this actually matters is when you're implementing some sort of
"insert into table if not yet present" operation. This will typically
result in a unique const
