Re: Locking concurrency: select for update vs update
От
Streamsoft - Mirek Szajowski
Тема
Re: Locking concurrency: select for update vs update
Дата
Msg-id
2af91a21-bdaf-f245-0b88-2046064ccce6@streamsoft.pl
Ответ на
Список
Дерево обсуждения
Locking concurrency: select for update vs update Streamsoft - Mirek Szajowski <m.szajowski@streamsoft.pl>
Re: Locking concurrency: select for update vs update Tom Lane <tgl@sss.pgh.pa.us>
Re: Locking concurrency: select for update vs update Streamsoft - Mirek Szajowski <m.szajowski@streamsoft.pl>
Re: Locking concurrency: select for update vs update Szymon Lipiński <mabewlun@gmail.com>
Re: Locking concurrency: select for update vs update Streamsoft - Mirek Szajowski <m.szajowski@streamsoft.pl>
Thanks
after your description I found select name from phone_number_type WHERE id_phone_number_type=4 for NO KEY update (Postgresql 9.3 )
W dniu 2016-06-07 o 15:24, Tom Lane pisze:
Streamsoft - Mirek Szajowski <m.szajowski@streamsoft.pl> writes:Why I can't execute 'select for update' but I can update?In recent PG versions, the lock held due to having inserted an FK dependent row effectively only locks the key fields of the parent row. UPDATE can tell whether you're trying to change the row's key fields, and it will proceed if you aren't. SELECT FOR UPDATE has to lock the whole row (since it must assume you might be intending to change any fields of the row); so it blocks until the FK lock goes away. regards, tom lane
В списке pgsql-performance по дате отправления