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. ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
