I am new to Postgres, and have not looked very carefully at transaction isolation in the past. However, I am not seeing the behaviour I would expect according to the Postgres docs. In particular, it seems I am not getting an error where expected for stale reads. This is for Postgres 12.
Assuming a table as follows
CREATE TABLE public.transactiontest (id int8 NULL, col_a varchar NULL);
INSERT INTO public.transactiontest (id, col_a) VALUES (1, 'aaa'), (2, 'bbb');
Executing on two sessions...
--Session 1
START TRANSACTION ISOLATION LEVEL SERIALIZABLE; --1
SELECT id, col_a FROM public.transactiontest; --2
--Session 2
START TRANSACTION ISOLATION LEVEL SERIALIZABLE; --3
SELECT id, col_a FROM public.transactiontest; --4
--Session 1
UPDATE public.transactiontest SET col_a = 'ccc' where id = 1; --5
COMMIT; --6
--Session 2
COMMIT; --7
I would have thought I would get an error at line 7, but the commit there goes through. It seems this would violate the docs
as if transactions had been executed one after another, serially, rather than concurrently.
because ordering the sessions 1 then 2 would give different results for line 4 than ordering 2 then 1.
What am I not understanding?
If session 2 were run before session 1, the result would be the same.
Consequently, the execution “first session2, then session 1” is a serialization of the workload.
That means that the workload is serializable.
It does not matter that session 1 started before session 2 in reality. As long as there is an equivalent serial execution, we are good.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With