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

Reply via email to