-----BEGIN PGP SIGNED MESSAGE-----
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 greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200701041708
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
In response to
pgsql-hackers by date
|Next:||From: Magnus Hagander||Date: 2007-01-04 22:22:48|
|Subject: Re: Problem with windows installer|
|Previous:||From: Tom Lane||Date: 2007-01-04 22:03:45|
|Subject: Re: [HACKERS] wal_checksum = on (default) | off |