Re: Rare corruption of pg_class index - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rare corruption of pg_class index
Date
Msg-id 5358.1167839417@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rare corruption of pg_class index  ("Greg Sabino Mullane" <greg@turnstep.com>)
Responses Re: Rare corruption of pg_class index  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-hackers
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> So as a general rule, the system tables should be considered a special
> case as far as transactional activity? To be more precise, you are saying
> that a system table must be locked in access exclusive mode before any
> change is made to guarantee no problems occur?

No, I didn't say that --- I said that you need to lock the table whose
schema you're trying to modify, to ensure that no one else is in the
midst of accessing it using the old schema info.

> So the oft-given advice of "UPDATE pg_class SET relhasrules = false"
> is actually completely unsafe unless the entire referenced table is
> completely locked, and unless you are using at least 8.2?

I don't recall having ever given *that* advice to anyone.  But yes,
it's unsafe if there might be concurrent access to that table.  The
only context I've ever seen people use this sort of thing in is
pg_restore --disable-triggers, and in that situation I think there's
an implicit assumption that no one else is busy modifying the table
you're restoring into.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Markus Schiltknecht
Date:
Subject: InitPostgres and flatfiles question
Next
From: Tom Lane
Date:
Subject: Re: InitPostgres and flatfiles question