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 [EMAIL PROTECTED]
End Point Corporation
PGP Key: 0x14964AC8 200701031037


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to