Re: [HACKERS] postgresql transactons not fully isolated - Mailing list pgsql-hackers

From J Chapman Flack
Subject Re: [HACKERS] postgresql transactons not fully isolated
Date
Msg-id c1ae0f75-8454-4851-3d89-3e379b0018ef@math.purdue.edu
Whole thread Raw
In response to [HACKERS] postgresql transactons not fully isolated  (Merlin Moncure <mmoncure@gmail.com>)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] [GSOC][weekly report 3] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Something is rotten in publication drop