Re: Lock table, best option? - Mailing list pgsql-general

From Josh Kupershmidt
Subject Re: Lock table, best option?
Date
Msg-id t2n4ec1cf761004251959l7c639186x96a36e307adc408b@mail.gmail.com
Whole thread Raw
In response to Lock table, best option?  (Andre Lopes <lopes80andre@gmail.com>)
List pgsql-general
On Sat, Apr 24, 2010 at 4:46 PM, Andre Lopes <lopes80andre@gmail.com> wrote:
> I need to do a SELECT and an UPDATE, but I will have concurrent processes
> doing the same task.
>
> How can I prevent that the concurrent task don't have the same results in
> the SELECT? Locking a table? How can I do that?

It sounds like you might be looking for SELECT ... FOR UPDATE, see:
http://www.postgresql.org/docs/current/static/sql-select.html

Basically, you could have each transaction issue SELECT ... FOR UPDATE
for rows intended to be updated later. Only one transaction would be
able to acquire the necessary locks for the same rows at the same
time; the other transaction(s) would block until the locks are
released by the first transaction's commit, and then would see the new
values. This paragraph assumes you're using the default "read
committed" transaction isolation level, you might want to read more
at:
http://www.postgresql.org/docs/current/static/transaction-iso.html

And if you really want to know about full table locking, you can read more at:
http://www.postgresql.org/docs/current/static/sql-lock.html

though it doesn't sound like you'll actually need full table locks.

Josh

pgsql-general by date:

Previous
From: Megha
Date:
Subject: Help with pgpool-dbt2 database
Next
From: Yan Cheng CHEOK
Date:
Subject: Deadlock occur while creating new table to be used in partition.