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.
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
