Skip site navigation (1) Skip section navigation (2)

Re: problems with table corruption continued

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: problems with table corruption continued
Date: 2001-12-19 03:56:40
Message-ID: 3C200FF8.6D344DC@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

regards,
Hiroshi Inoue

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-12-19 04:06:34
Subject: Re: checkpoint reliability
Previous:From: Lamar OwenDate: 2001-12-19 03:47:18
Subject: Re: Thoughts on the location of configuration files

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group