Re: [HACKERS] postgresql transactons not fully isolated
От | J Chapman Flack |
---|---|
Тема | Re: [HACKERS] postgresql transactons not fully isolated |
Дата | |
Msg-id | c1ae0f75-8454-4851-3d89-3e379b0018ef@math.purdue.edu обсуждение исходный текст |
Ответ на | [HACKERS] postgresql transactons not fully isolated (Merlin Moncure <mmoncure@gmail.com>) |
Список | pgsql-hackers |
On 06/20/2017 12:33 PM, Merlin Moncure wrote: > postgres=# create table ints (n int); > CREATE TABLE > postgres=# insert into ints values (1); > INSERT 0 1 > postgres=# insert into ints values (2); > INSERT 0 1 > > T1: BEGIN > T1: UPDATE ints SET n = n + 1; > T2: BEGIN > T2: DELETE FROM ints where n = 2; -- blocks > T1: COMMIT; -- T2 frees > T2: SELECT * FROM ints; -- both rows 2 and 3 visible > T2: COMMIT: For me (in PG 9.5 at $work), at the instant of the commit in T1, T2 says: ERROR: could not serialize access due to concurrent update Is it indicated what PG version Michael Malis is using? Is it clear that transaction_isolation was set to serializable? I don't actually see that claim in the linked post. I see the example (about halfway down, under "Skipped Modification"), but it doesn't claim that transaction_isolation was set to serializable at the time, unless I skimmed over it somehow. It seems more of a demonstration of what can happen under a different isolation setting. -Chap
В списке pgsql-hackers по дате отправления: