Re: [PERFORM] Locking concurrency: select for update vs update

2016-06-07 Thread Streamsoft - Mirek Szajowski
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 writes: Why I can't execute 'select for update' but I can update? In recent

Re: [PERFORM] Locking concurrency: select for update vs update

2016-06-07 Thread Tom Lane
Streamsoft - Mirek Szajowski 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 f

Re: [PERFORM] Locking concurrency: select for update vs update

2016-06-07 Thread Streamsoft - Mirek Szajowski
It means that second TX hangs/wait on this sql code FIRST TX INSERT INTO phone_number( id_phone_number,id_phone_number_type) VALUES (1,500); SECOND TX select * from phone_number_type WHERE id_phone_number_type=500 for update //hangs/wait to TX with insert into ends but this works

Re: [PERFORM] Locking concurrency: select for update vs update

2016-06-07 Thread Szymon LipiƄski
On 7 June 2016 at 09:31, Streamsoft - Mirek Szajowski < m.szajow...@streamsoft.pl> wrote: > Hello, > > I have two tables phone_number and phone_number_type > > When I start transaction and insert phone_number using FK from > phone_number_type. Then I can during another TX update row from > phone_n