Re: Re: How to reproduce serialization failure for a read only transaction. - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Re: How to reproduce serialization failure for a read only transaction.
Date
Msg-id 52CB3E58.7030100@nasby.net
Whole thread Raw
In response to Re: Re: How to reproduce serialization failure for a read only transaction.  (Florian Pflug <fgp@phlo.org>)
Responses Re: How to reproduce serialization failure for a read only transaction.
List pgsql-hackers
On 1/6/14, 5:27 PM, Florian Pflug wrote:> On Jan6, 2014, at 23:28 , AK <alkuzo@gmail.com> wrote:> First, dependency
trackingcan produce false positives, i.e. assume that> dependencies exist between transactions which are actually
independent.>In my example, postgres fails to realize that W2 can be executed after W1,> unless it uses an index scan
forthe UPDATE in W2. You can avoid that either> by creating an index on the id column, and forcing W2 to use that by
setting>enable_seqscan to off, or by creating two tables t1 and t2 instead of one> table t with two records (You'll
haveto modify the SELECT to scan both tables> too).>> Second, since R executes it's SELECT before W1 commits, postgres
isalready> aware that R poses a problem when W1 commits, and it chooses to cancel W1> instead of R. To avoid that, R
needsto do the SELECT after W1 committed.> Yet still force R to acquire a snapshot *before* that commit (without that,>
there'sno serialization failure since R than simply executes after W1 and> W2), you'll need to do e.g. SELECT 1 after
R'sSTART TRANSACTION command.>> I think the following should work (or, rather, fail)
 

This email and the previous one are an awesome bit of information, can we add it to the docs somehow? Even if it's just
dumpingthe emails into a wiki page and referencing it?
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: Re: How to reproduce serialization failure for a read only transaction.
Next
From: Jim Nasby
Date:
Subject: Re: dynamic shared memory and locks