Re: psycopg concurrency control
| От | John Lb |
|---|---|
| Тема | Re: psycopg concurrency control |
| Дата | |
| Msg-id | CANqFGQxwp-0D=1Gx2Px1hHsVWa7XdFH0n7piT7oStaPwmJa20A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: psycopg concurrency control (Christophe Pettus <xof@thebuild.com>) |
| Список | 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 по дате отправления: