From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [WIP] The relminxid addition, try 3 |
Date: | 2006-05-26 03:03:22 |
Message-ID: | 20060526030322.GT13700@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> I wrote:
> > Well, that needs rethinking. The unfreeze has to be a non-transactional
> > update (if our transaction rolls back, the unfreeze still has to
> > "stick", because we may have put dead tuples into the rel).
>
> Actually, this seems even messier than I thought. Consider a
> transaction that does something transactional to a table's schema,
> thereby generating a new pg_class row (but not touching any data within
> the table), and then alters the table contents, requiring an unfreeze.
> An update to the apparently-current pg_class tuple is not good because
> that tuple might be rolled back. An update to the last committed
> version doesn't work either.
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.
Not that I had actually considered this problem, to be frank; but it
seems a nice side effect of how the unfreezing works.
> This seems real close to the recent discussions about how to put
> sequence data into a single one-row-per-sequence system catalog,
> specifically about how there were some parts of the sequence catalog
> data that should be transactional and some that should not be.
> 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.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-26 03:09:51 | Re: [WIP] The relminxid addition, try 3 |
Previous Message | Tom Lane | 2006-05-26 02:43:31 | Re: [WIP] The relminxid addition, try 3 |