Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> Where did all these CommandCounterIncrement calls come from?
> I added them in heap_unfreeze precisely because I want the relation to
> be frozen exactly once, and this doesn't seem to happen if I don't CCI
> there -- I was seeing multiple occurences of the NOTICE I put in
> heap_unfreeze for the same relation for a single CREATE TABLE (multiple
> unfreezes of pg_class and pg_attribute, for example).
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). Therefore,
a CCI is neither necessary nor useful. I didn't look at your patch in
any detail ... didn't you modify it to use the non-transactional update
code I put in heapam.c recently?
It might be that we need to broadcast an sinval message for the tuple
when we update it this way ... although sinval believes updates are
transactional, so that's not going to work all that well. Maybe we have
to legislate that catcache/syscache entries shouldn't be trusted to have
up-to-date values of these fields.
regards, tom lane
