Re: Row level locking

Поиск
Список
Период
Сортировка
От Carlos Benkendorf
Тема Re: Row level locking
Дата
Msg-id 20051013083229.70827.qmail@web35503.mail.mud.yahoo.com
обсуждение исходный текст
Ответ на Re: Row level locking  (Michael Fuhr <mike@fuhr.org>)
Ответы Re: Row level locking  (Michael Fuhr <mike@fuhr.org>)
Список pgsql-general
I agree that select for update will be the best choice but it does not have any effect with insert statements.
 
if you try the following sequence in two different transactions, the select for update will succeed but the insert will be blocked.
 
begin transaction;
select employee_id from employees where employee_id=3 for update;
insert into employees values (3,33);
create table employees
(employee_id integer primary key,
 other_id integer);
 
Michael Fuhr <mike@fuhr.org> escreveu:
On Wed, Oct 12, 2005 at 09:30:50PM +0800, Lincoln Yeoh wrote:
> will "lock sometable nowait" help?
>
> http://developer.postgresql.org/docs/postgres/sql-lock.html
>
> If it fails, something is in progress.

And if it succeeds then it might hurt the performance of concurrent
transactions, depending on which lock mode you use. Using SELECT
FOR UPDATE with a statement timeout might have less impact if you
only need to work with certain rows, and 8.1 will have SELECT FOR
{ UPDATE | SHARE } [ NOWAIT ].

Carlos, you said the applications were doing only inserts. Is that
right? Have you investigated what's causing the blocking? Do the
rows you're inserting have foreign key references? Let's find out
what the problem is before suggesting how to solve it.

--
Michael Fuhr

---------------------------(end o f broadcast)---------------------------
TIP 6: explain analyze is your friend


Promoção Yahoo! Acesso Grátis: a cada hora navegada você acumula cupons e concorre a mais de 500 prêmios! Participe!

В списке pgsql-general по дате отправления:

Предыдущее
От: Stuart Bishop
Дата:
Сообщение: Re: PostgreSQL's bug tracker
Следующее
От: Andrew Kelly
Дата:
Сообщение: Re: Limitations of PostgreSQL