Thread: [GENERAL] postgresql : could not serialize access due to read/writedependencies among transactions

Hi , 


I have problem about  this issue ; 


could not serialize access due to read/write dependencies among transactions


message app like whatsapp i decided to use isolation level serializable if i use other transaction levels many conversations started with same number (think about whatsapp web sidebar multipling with same number every message).


I also add an index to my query and my query's execution plan don't use seq scan .


How can i solve this issue ? Can i solve this on db orr on app  ?


Neslişah Demirci | Veritabanı Yöneticisi 

Ayazağa cad. No:4 Uniq İstanbul Plaza
B2 /Kat:3 34396 Ayazağa-SARIYER-İstanbul
T. (+90) 212 453 16 00 – 5516
F. (+90) 212 453 16 16
www.markafoni.com
www.facebook.com/markafoni
blog.markafoni.com



On 1/17/2017 8:54 PM, Neslisah Demirci wrote:


could not serialize access due to read/write dependencies among transactions


only way to answer this would be to know what the various concurrent transactions are doing.

message app like whatsapp i decided to use isolation level serializable if i use other transaction levels many conversations started with same number (think about whatsapp web sidebar multipling with same number every message).


again, we'd need to know what your transactions are doing.   what you're describing sounds inherently incorrect, like you're doing too much in the application and not enough in the database


I also add an index to my query and my query's execution plan don't use seq scan .


that has no bearing on the above problems.


-- 
john r pierce, recycling bits in santa cruz
On Tue, Jan 17, 2017 at 10:54 PM, Neslisah Demirci
<neslisah.demirci@markafoni.com> wrote:

> could not serialize access due to read/write dependencies among
> transactions

> I also add an index to my query and my query's execution plan
> don't use seq scan .

These two issues are likely to be somewhat related -- if a
sequential scan is used, then any write to that table by another
connection causes a read-write dependency (a/k/a rw-conflict),
which can eventually contribute to a serialization failure.  If you
can cause narrower access through indexes, you may see a
significant drop in the frequency of these serialization failures.
You might want to post the query and its execution plan with all
the information suggested here (exact pg version, configuration
information, machine descriptions, etc.):

https://wiki.postgresql.org/wiki/SlowQueryQuestions

On the other hand, if you are going to use serializable
transactions (or even repeatable read transactions) you should
probably be using some framework that can retry the transaction
from the start on a serialization failure.

You might be interested in this set of examples of how serializable
transactions differ from repeatable read:

https://wiki.postgresql.org/wiki/SSI

And of course, if you haven't already read the fine manual on the
topic:

https://www.postgresql.org/docs/current/static/mvcc.html

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company