Re: [GENERAL] SELECT blocks UPDATE

2015-08-13 Thread Tom Lane
twoflower writes: > Tom Lane-2 wrote >> So either the SELECT is a SELECT FOR UPDATE, or it's part of a transaction >> that's done datachanges in the past. > If these are the only two explanations, it must be the latter then. What I > still don't understand - these two statements are part of the s

Re: [GENERAL] SELECT blocks UPDATE

2015-08-13 Thread Adrian Klaver
On 08/13/2015 02:14 PM, twoflower wrote: Further observation: Now I managed to get rid of the blocking. I am not sure if you are familiar with the NHibernate ORM, but it has a concept of a stateful and stateless sessions. Session holds a connection to the database and transaction is created on a

Re: [GENERAL] SELECT blocks UPDATE

2015-08-13 Thread twoflower
Further observation: Now I managed to get rid of the blocking. I am not sure if you are familiar with the NHibernate ORM, but it has a concept of a stateful and stateless sessions. Session holds a connection to the database and transaction is created on a particular session. In this case, 'begin tr

Re: [GENERAL] SELECT blocks UPDATE

2015-08-13 Thread twoflower
The Postgres version is 9.3.9. The actual output of the lock query is (I added *locktype* and *mode* columns from the *pg_locks* table) *blocked_pid*: 7574 *blocked_statement*: UPDATE "TRANSLATION" SET fk_assignment_queue_item = 1009184 WHERE id IN (47049861) *blocked_locktype*: transactionid *b

Re: [GENERAL] SELECT blocks UPDATE

2015-08-13 Thread Tom Lane
twoflower writes: > if I am reading the documentation on explicit locking > > > correctly, SELECT should never conflict with UPDATE. Pure SELECT, I would think not. But is it really a SELECT FOR UPDATE?

Re: [GENERAL] SELECT blocks UPDATE

2015-08-13 Thread Adrian Klaver
On 08/13/2015 06:39 AM, twoflower wrote: Hello, if I am reading the documentation on explicit locking correctly, SELECT should never conflict with UPDATE. However, what I am observing as a result of this mo

[GENERAL] SELECT blocks UPDATE

2015-08-13 Thread twoflower
Hello, if I am reading the documentation on explicit locking correctly, SELECT should never conflict with UPDATE. However, what I am observing as a result of this monitoring query: SELECT bl.pid AS bloc