Select for update / deadlock possibility? - Mailing list pgsql-general

From Durumdara
Subject Select for update / deadlock possibility?
Date
Msg-id CAEcMXhnS+h8Luy7eosgkVHJgXZorjGQZ+9OP6TZrzkZWXCFgxg@mail.gmail.com
Whole thread Raw
Responses Re: Select for update / deadlock possibility?  ("Rakesh Kumar" <rakeshkumar464@mail.com>)
Re: Select for update / deadlock possibility?  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-general
Dear Members!

I have to ask something that not clear for me from description, and I can't simulate it.

Is "select for update" atomic (as transactions) or it isn't?

I want to avoid the deadlocks.

If it's atomic, then I don't need to worry about concurrent locks.
But I think it's not. 

This is an example for deadlock:

a.) select * from test where id in (1, 3, 4)
b.) select * from test where id in (2, 4, 5)
c.) select * from test where id in (5, 1, 6)

If it's not atomic, then:

- a locks 1.
- b locks 2.
- c locks 5.
- a locks 3.
- b locks 4.
- c try to lock 1, but it locked by a
- a try to lock 4, but it locked by b
- b try to lock 5, but it locked by c

DEADLOCK!!!

As I read select for update doesn't support timeout.
I've found two timeout that could be affects on it.
Which one I need to redefine temporarily?

lock_timeout (integer)
statement_timeout (integer)

Somebody wrote statement_timeout, but why PG have lock_timeout then?

Thank you for your help!

Regards
dd


pgsql-general by date:

Previous
From: Jov
Date:
Subject: Re: Returning Values from INSERT ON CONFLICT DO NOTHING
Next
From: Alexander Farber
Date:
Subject: Re: Selecting a JSON object of arrays from a PostgreSQL table