-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
In response to
pgsql-hackers by date
|Next:||From: Markus Schiltknecht||Date: 2007-01-03 15:49:51|
|Subject: InitPostgres and flatfiles question|
|Previous:||From: Jim Nasby||Date: 2007-01-03 15:40:38|
|Subject: Re: TODO: Add a GUC to control whether BEGIN inside|