Re: psycopg concurrency control - Mailing list psycopg

From Christophe Pettus
Subject Re: psycopg concurrency control
Date
Msg-id 56ECBEC2-B692-4EF8-99C4-70CF526C3675@thebuild.com
Whole thread Raw
In response to psycopg concurrency control  (John Lb <johnlb77@gmail.com>)
List psycopg
On Sep 12, 2016, at 3:43 PM, John Lb <johnlb77@gmail.com> wrote:
> I  did  some more  documentation  reading  and  I  noticed that   I can  use  the  LOCK command   example :   LOCK
TABLEmytable IN ACCESS EXCLUSIVE MODE  .     Reason for ACCESS EXCLUSIVE is  that  there is tip  in the documentation
thatsays    only  ACCESS EXCLUSIVE  can block a    SELECT. 
>
> Am  I thinking right ??

You are correct in that is the only lock mode that will block a SELECT.  Note that this means you will effectively have
threadsgoing single-file through the database, with very significant performance penalties. 

You might consider using SELECT ... FOR UPDATE instead of a explicit table-level lock.  This will prevent changes to
therows that the thread is working on, while not blocking SELECT ... FOR UPDATE against a different set of rows. 

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

Yes, because there is effectively no concurrency in the database, now.

--
-- Christophe Pettus
   xof@thebuild.com



psycopg by date:

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