Re: psycopg concurrency control

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(at)thebuild(dot)com> wrote:

>
> On Sep 11, 2016, at 8:26 AM, John Lb <johnlb77(at)gmail(dot)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(at)thebuild(dot)com
>
>