-----BEGIN PGP SIGNED MESSAGE----- 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 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFFm83kvJuQZxSWSsgRAvhiAJ0TEgzg3mkZ6BKvlR7jHKY96JVmmACgxrYb pFY851yrZd5bh7GHaR+k0Q4= =FgL+ -----END PGP SIGNATURE----- ---------------------------(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 match
