Alvaro Herrera <[EMAIL PROTECTED]> writes: > Well, if a transaction modifies a table in some way, even without > changing the data, should generate an unfreeze event, because it will > need to lock the table; for example AlterTable locks the affected > relation with AccessExclusiveLock. It's important for the > non-transactional change to the pg_class tuple be the very first in the > transaction, because otherwise the change could be lost; but other than > this, I don't think there's any problem.
You can't guarantee that. Consider for instance manual updates to pg_class: BEGIN; UPDATE pg_class SET reltriggers = 0 WHERE relname = ... ... alter table contents ... COMMIT or ROLLBACK; I believe there are actually patterns like this in some pg_dump output. Will you hack every UPDATE operation to test whether it's changing pg_class and if so force an "unfreeze" operation before changing any row? No thanks :-( >> I'm wondering if we need a second pg_class-derived catalog that carries >> just the nontransactional columns. > I hope we don't need to do this because ISTM it will be a very big change. (Yawn...) We've made far bigger changes than that. The important thing is to get it right. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend