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

Re: Rare corruption of pg_class index

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rare corruption of pg_class index
Date: 2007-01-03 15:43:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Hash: SHA1

Tom Lane wrote:
> No, it's not a violation of ACID.  In this case what you are doing is
> altering a table's schema without a sufficiently strong lock on the
> table, and that's a no-no, whether you would like it to be or not.

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?

> Well, ENABLE/DISABLE TRIGGER can't conceivably operate correctly without
> locking out writes, because it wouldn't be clear whether any particular
> write operation should fire the trigger or not.  A hypothetical
> ENABLE/DISABLE RULE would be worse: AFAICS it'd have to lock out reads
> too, else it wouldn't be clear whether SELECTs should notice an ON
> SELECT rule.  You can't get around those restrictions by trying to
> implement the enable/disable yourself via UPDATE pg_class; as you've
> found out, it just doesn't work.

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?

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200701031037


In response to


pgsql-hackers by date

Next:From: Markus SchiltknechtDate: 2007-01-03 15:49:51
Subject: InitPostgres and flatfiles question
Previous:From: Jim NasbyDate: 2007-01-03 15:40:38
Subject: Re: TODO: Add a GUC to control whether BEGIN inside

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