Re: problems with table corruption continued
От | Tom Lane |
---|---|
Тема | Re: problems with table corruption continued |
Дата | |
Msg-id | 19687.1008721763@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: problems with table corruption continued (Hiroshi Inoue <Inoue@tpf.co.jp>) |
Ответы |
Re: problems with table corruption continued
|
Список | pgsql-hackers |
Hiroshi Inoue <Inoue@tpf.co.jp> writes: > I don't remember well if there was a really dangerous(scan an relation > opened with NoLock) place. I have just looked for that, and the only such place is in the new contrib module pgstattuple. This is clearly broken, since there is nothing stopping someone from (eg) dropping the relation while pgsstattuple is scanning it. I think it should get AccessShareLock on the relation. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: