Re: Add cassert-only checks against unlocked use of relations
От | Tom Lane |
---|---|
Тема | Re: Add cassert-only checks against unlocked use of relations |
Дата | |
Msg-id | 31989.1383687949@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add cassert-only checks against unlocked use of relations (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Add cassert-only checks against unlocked use of
relations
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2013-11-05 16:25:53 -0500, Tom Lane wrote: >> If we're sufficiently worried by this type of bug, ISTM we'd be better off >> just disallowing heap_open(NoLock). At the time we invented that, every >> lock request went to shared memory; but now that we have the local lock >> table, re-locking just requires a local hash lookup followed by >> incrementing a local counter. That's probably pretty cheap --- certainly >> a lot cheaper than what you've got here. > Hm. That only works though if we're using the same lockmode as before - > often enough the *_open(NoLock) checks would use a weaker locklevel than > the previous lock. So I think the cost of doing so would probably be > noticeable. If you're not using the same lockmode as before, it's probably a bug anyway. As I said already, the entire NoLock coding technique is dependent on having a very clear idea of which previous lock-taking you're riding on the coattails of. Why wouldn't you duplicate that lock level, if we say you can't use NoLock anymore? regards, tom lane
В списке pgsql-hackers по дате отправления: