Re: [HACKERS] FOR SHARE LOCK clause ?
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] FOR SHARE LOCK clause ? |
Дата | |
Msg-id | 199901060425.XAA23336@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] FOR SHARE LOCK clause ? (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
> Bruce Momjian wrote: > > > > > > I think lock escalation is nice. Locking every row makes for lock > > > > resource problems. I would recommend locking a single row, and if a > > > > second row needs to be locked, just escalate to lock the whole table... > > > > if that can be done. This would seem to be the most reasonable and > > > > easiest to do. > > > > > > Easiest to do is don't worry about # of locks -:) > > > Let's be on this way for 6.5 > > > > You mean just share-lock the whole table. I agree. It is a pretty rare > > situation. > > No. User may use LOCK TABLE IN SHARE MODE for this. > I propose SELECT FOR SHARE LOCK as alternative to > LOCK TABLE IN SHARE MODE and SELECT FOR UPDATE and > would like to share lock each row selected with > FOR SHARE LOCK clause in use. I don't know what's > real limitations of # locks, but I think that > a tens of locks is Ok. So you are going to shared lock every row. And if a user does a sequential scan of the entire table using SELECT FOR SHARE LOCK, he shared locks every row. Isn't he going to run out of locks? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: