Hash: SHA1

Tom Lane replied:
>> 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.

Sorry, I did mean the target table.

>> 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.

Not, not your advice, and perhaps not as common as SET reltriggers, but
still invaluable for things like bulk loading. Thanks for the responses,
I think I've finally got my head around the problem. At the very least,
I've discovered another good reason to push production sites to use

- --
Greg Sabino Mullane [EMAIL PROTECTED]
End Point Corporation
PGP Key: 0x14964AC8 200701041708


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to