Re: 'locking' the SELECTs based on indices...
От | Mario Splivalo |
---|---|
Тема | Re: 'locking' the SELECTs based on indices... |
Дата | |
Msg-id | 1140689618.5002.9.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: 'locking' the SELECTs based on indices... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-sql |
On Wed, 2006-02-22 at 13:58 -0500, Tom Lane wrote: > Mario Splivalo <mario.splivalo@mobart.hr> writes: > > Now, when I do this from one connection (psql shell, for instance): > > > [A]BEGIN TRANSACTION; > > [A]SELECT * FROM bla WHERE code_id = 1 FOR UPDATE; > > > and then, from another psql i do: > > [B]SELECT * FROM bla WHERE code_id = 1 FOR UPDATE > > > the second SELECT will wait untill I rollback or commit first > > transaction. That is cool. > > > But, if I do second SELECT like this: > > > [C]SELECT * FROM bla WHERE code_id = 2 FOR UPDATE > > > I will get the rows. > > Well, of course. Why would you want something different? Why do you > think the table's indexes should have anything to do with it? > > If you want a full-table lock then some form of LOCK TABLE seems like > the proper answer. SELECT FOR UPDATE is designed to lock the specified > rows, no more. Hm. But, is there a way to have just a part of table locked, for instance: BEGIN; SELECT * FROM bla WHERE code_id = 1 AND code_value = 'abla' FOR UPDATE and then, in second connection: BEGIN; SELECT * FROM bla WHERE code_id = 1 AND code_value = 'eble' FOR UPDATE I'd like to have second SELECT to hold. Now I'm doing it like this: First connection: BEGIN; SELECT * FROM bla WHERE code_id = 1 FOR UPDATE -- this is just for lock SELECT * FROM bla WHERE code_id = 1 AND code_value = 'abla' FOR UPDATE ... Second connection: BEGIN; SELECT * FROM bla WHERE code_id = 1 FOR UPDATE -- here it'll wait SELECT * FROM bla WHERE code_id = 1 AND code_value = 'eble' FOR UPDATE Since I'm actually doing this inside of a function, i'll use PERFORM for the first select. The problem is that SELECT COUNT(*) FROM bla WHERE code_id = 1 will return some 10M rows (on live data, my test data has some 100k rows, and I don't see any performance impact - yet). Is this a right way to go? > > If I erase the index bla_idx1, then [C] select will wait, same as [B] > > select will wait. > > I don't think so. If it does, it's a bug; please provide a reproducible > test case. > It's not a bug. My high fever must have something to do with it. I just tried it, removed the index, and [C] isn't waiting. Mike
В списке pgsql-sql по дате отправления: