Re: An example needed for Serializable conflict...

Hi!

Thanks for your help!

Another question if I use only "SELECTS" can I get some Serialization Error?

For example:
I need a report tool that can show the actual state of the business.
Because of I use value-dependent logic, I MUST use consistent state to
preserve the equality of many values (sums, counts, etc.).

So some (Read Committer) threads are update/delete/insert (sum modify)
rows, but this report tool only READ the tables, and only works for temp
tables.

Can I get some S. error from this transaction?
Or can I get some error from modifier threads if this (serializer
report) thread actually read the rows that they are want to modify?

This is the main question about it.

Thanks for your read/answer!

dd

2009.07.07. 11:36 keltezéssel, Albe Laurenz írta:
> Durumdara wrote:
>
>> Please send me an example (pseudo-code) for Serializable conflict.
>> And I wanna know, if possible, that if more transactions only
>> read the tables in Serializable mode, and one or others write
>> to it, can I got some conflicts in read operation?
>>
>
> You get a serialization conflict if you try to modify a row
> in a serializable transaction T1 that has been changed by a second
> transaction T2 after T1 started.
>
> Sample 1:
>
> T1: START TRANSACTION ISOLATION LEVEL SERIALIZABLE;
>
> T1: SELECT * FROM t;
> id | val
> ----+------
> 1 | test
> (1 row)
>
> T2: DELETE FROM t WHERE id=1;
>
> T1: UPDATE t SET val='new' WHERE id=1;
> ERROR: could not serialize access due to concurrent update
>
> Sample 2:
>
> T1: START TRANSACTION ISOLATION LEVEL SERIALIZABLE;
>
> T1: SELECT * FROM t;
> id | val
> ----+------
> 1 | test
> (1 row)
>
> T2: UPDATE t SET val=val WHERE id=1;
>
> T1: DELETE FROM t;
> ERROR: could not serialize access due to concurrent update
>
>
> Yours,
> Laurenz Albe
>