Re: problems with table corruption continued
От | Stephan Szabo |
---|---|
Тема | Re: problems with table corruption continued |
Дата | |
Msg-id | 20011218202808.Y66402-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: problems with table corruption continued (Hiroshi Inoue <Inoue@tpf.co.jp>) |
Список | pgsql-hackers |
On Wed, 19 Dec 2001, Hiroshi Inoue wrote: > Stephan Szabo wrote: > > > > On Tue, 18 Dec 2001, Tom Lane wrote: > > > > > The ri_triggers code has a lot of places that open things NoLock, > > > but it only looks into the relcache entry and doesn't try to scan > > > the relation. Nonetheless that code bothers me; we could be using > > > an obsolete relcache entry if someone has just committed an ALTER > > > TABLE on the relation. Some of the cases may be safe because a lock > > > is held higher up (eg, on the table from which the trigger was fired) > > > but I doubt they all are. > > > > Probably not, since it looks like that's being done for the other table of > > the constraint (not the one on which the trigger was fired). > > If a lock is held already, acquiring an AccessShareLock > would cause no addtional conflict. I don't see any reason > to walk a tightrope with NoLock intentionally. I don't know why NoLock was used there, I was just pointing out that the odds of a lock being held higher up is probably low.
В списке pgsql-hackers по дате отправления: