Re: problems with table corruption continued - Mailing list pgsql-hackers

From Tom Lane
Subject Re: problems with table corruption continued
Date
Msg-id 19687.1008721763@sss.pgh.pa.us
Whole thread Raw
In response to Re: problems with table corruption continued  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Responses Re: problems with table corruption continued  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Possible bug in vacuum redo
Next
From: Hannu Krosing
Date:
Subject: Re: Concerns about this release