Tom Lane wrote: > 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 :-(
Oh, true, I hadn't thought of direct updates to pg_class. > >> 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. Yeah, I know -- I've been involved in some of them. I hereby volunteer to do it for 8.2 because I'd really like to see this patch in. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
