From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [WIP] The relminxid addition, try 3 |
Date: | 2006-05-26 03:09:51 |
Message-ID: | 18516.1148612991@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-05-26 03:34:29 | Re: [WIP] The relminxid addition, try 3 |
Previous Message | Alvaro Herrera | 2006-05-26 03:03:22 | Re: [WIP] The relminxid addition, try 3 |