| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
| Cc: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, Brian Hirt <bhirt(at)mobygames(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>, Brian A Hirt <bhirt(at)berkhirt(dot)com> |
| Subject: | Re: problems with table corruption continued |
| Date: | 2001-12-19 00:29:23 |
| Message-ID: | 19687.1008721763@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-12-19 01:04:12 | Re: Concerns about this release |
| Previous Message | Andrew G. Hammond | 2001-12-19 00:29:17 | Re: Explicit config patch 7.2B4 |