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

From: "Gunnar \"Nick\" Bluth" <gunnar(dot)bluth(dot)extern(at)elster(dot)de>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: postgresql : could not serialize access due to read/write dependencies among transactions
Date: 2017-02-10 10:23:20
Message-ID: debbe02c-035d-04c8-ce40-f7e95529e196@elster.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-general

Am 01/18/2017 um 05:54 AM schrieb Neslisah Demirci:
> Hi ,
>
>
> I have problem about this issue ;
>
>
> could not serialize access due to read/write dependencies among transactions

That's something you have to expect when using SERIALIZABLE isolation
level. Maybe re-read
https://www.postgresql.org/docs/current/static/transaction-iso.html#XACT-SERIALIZABLE

> A 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).

Are you not using a sequence for generating these IDs? As those are
counting independent of transaction visibility...
What you say sounds more like "SELECT max(conversation_id) + 1 AS
new_conversation_id FROM ..."

> 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 ?

a) switch to a sequence for generating these IDs (you can go back to a
lower isolation level then). You may get holes in the IDs then (on
rolled back transactions), but I don't see how that would not be
acceptable for conversation IDs
b) deal with it in the app (probably not what you want, think roud-trip
time)

> 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 <http://www.markafoni.com/>
> www.facebook.com/markafoni <http://www.facebook.com/markafoni>
> blog.markafoni.com
>
>
>

Regards,
--
Gunnar "Nick" Bluth
DBA ELSTER

Tel: +49 911/991-4665
Mobil: +49 172/8853339

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Lazaro Garcia 2017-02-10 15:14:20 Re: [pgpool-general: 5318] Why pgpool TPS is lowest versus postgresql direct connections?
Previous Message Tom Lane 2017-02-09 17:46:43 Re: Very long index build time

Browse pgsql-general by date

  From Date Subject
Next Message Steven Winfield 2017-02-10 12:05:25 Re: Build exclusion constraints USING INDEX
Previous Message Jehan-Guillaume de Rorthais 2017-02-10 10:15:43 Re: clarification about standby promotion