Re: psycopg concurrency control - Mailing list psycopg

From John Lb
Subject Re: psycopg concurrency control
Date
Msg-id CANqFGQxwp-0D=1Gx2Px1hHsVWa7XdFH0n7piT7oStaPwmJa20A@mail.gmail.com
Whole thread Raw
In response to Re: psycopg concurrency control  (Christophe Pettus <xof@thebuild.com>)
List psycopg
Thanks for the reply.

I will be a more specific now .   Instead of writer  ,  I  must say   it is  a  read ,  modify  and then  write operation .
The  situation is that  first   I do  a  SELECT ,   based on the read  data   the following instruction can be either   INSERT ,  UPDATE  or  do nothing,  then   commit  and the close .   
When  a  thread  is  doing a  SELECT ,   I want to block  all the other threads for doing a  SELECT  on the  same table .  So   I want  only  one thread  to have access to the table  at a time . Other threads must wait.

I  did  some more  documentation  reading  and  I  noticed that   I can  use  the  LOCK command   example :   LOCK TABLE mytable IN ACCESS EXCLUSIVE MODE  .     Reason for ACCESS EXCLUSIVE is  that  there is tip  in the documentation that says    only  ACCESS EXCLUSIVE  can block a    SELECT.

Am  I thinking right ??

Further   a question :     when doing this  way  ,   the  Read Committed Isolation level can  stay  default ??

Thanks



On Sun, Sep 11, 2016 at 7:47 PM, Christophe Pettus <xof@thebuild.com> wrote:

On Sep 11, 2016, at 8:26 AM, John Lb <johnlb77@gmail.com> wrote:
> I am not a  Postgres guy  but  I tried to  read the  documentation and  I  believe that   Explicit Locking -->  Table level Locks -->  ROW EXCLUSIVE  are the way to go .

You almost certainly *don't* have to do any explicit locking, even with writers to the same table; PostgreSQL will largely handle the concurrency issues for you.  Note that once a particular connection has written to an (existing) row, no other session can write to that same row until the first session commits or aborts; the second session will wait for the first transaction to finish.

--
-- Christophe Pettus
   xof@thebuild.com


psycopg by date:

Previous
From: Christophe Pettus
Date:
Subject: Re: psycopg concurrency control
Next
From: John Lb
Date:
Subject: Re: psycopg concurrency control