| From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
|---|---|
| To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: problems with table corruption continued |
| Date: | 2001-12-19 04:29:24 |
| Message-ID: | 20011218202808.Y66402-100000@megazone23.bigpanda.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hiroshi Inoue | 2001-12-19 04:33:49 | Re: checkpoint reliability |
| Previous Message | Bruce Momjian | 2001-12-19 04:10:20 | Re: checkpoint reliability |