Timeline for Allow only one reader to a table
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 8, 2018 at 13:35 | history | edited | Emilio Platzer | CC BY-SA 4.0 |
typos
|
| Sep 5, 2018 at 8:29 | vote | accept | garg10may | ||
| Sep 4, 2018 at 14:15 | history | edited | Emilio Platzer | CC BY-SA 4.0 |
add better solutions
|
| Sep 4, 2018 at 13:50 | history | edited | Emilio Platzer | CC BY-SA 4.0 |
lack of "conn.commit()"
|
| Sep 3, 2018 at 20:00 | comment | added | user1822 | @EmilioPlatzer: if both transactions were only using UPDATE, the same thing would happen. Plus: Gerard is right: an `update ... returning" would make the select unnecessary | |
| Sep 3, 2018 at 19:57 | comment | added | Gerard H. Pille | Does postgres know "update ... returning ..." ? | |
| Sep 3, 2018 at 13:44 | comment | added | Emilio Platzer | If you do not do the "FOR UPDATE" can hapens this: The SELECT obtains port number 77, concurrently in other transaction the SELECT obtains again the number 77, then in the first transaction the UPDATE locks the record and sets avaialbe='f' then the other transaction do the same upates the same record seting avaiable='f'. If you put "FOR UPDATE" when the second SELECT want to get the avaiable port "FOR UPDATE" must wait that the first transaction commits; then the SELECT was executed and the next avaiable port was getted. | |
| Sep 3, 2018 at 13:32 | comment | added | user1822 |
The UPDATE statement will lock the row the same way SELECT ... FOR UPDATE will. There is no need to do SELECT FOR UPDATE beforehand if you are doing an UPDATE immediately afterwards. Only doing the UPDATE is sufficient and less work for the database. If you are not even sure the two statements are sent "immediately" after another sending only a single statement is even more important.
|
|
| Sep 3, 2018 at 13:24 | comment | added | Emilio Platzer | @a_horse_with_no_name I do not agree with you. I believe that is necesary. The "for update" locks the row as garg10may needs. Are you shure that in python the two sentences are sended "immediately following"? I sure that in node.js may not! Are you sure that in pure postgresql two transactions may not run concurrently or if they do they do not interrupt SELECT/UPDATE pairs of immeediate sentences? postgresql.org/docs/9.5/static/… postgresql.org/docs/9.5/static/… | |
| Sep 3, 2018 at 13:10 | comment | added | user1822 |
The SELECT FOR UPDATE is unnecessary if immediately followed by an UPDATE
|
|
| Sep 3, 2018 at 12:51 | history | answered | Emilio Platzer | CC BY-SA 4.0 |