Re: [WIP] The relminxid addition, try 3
От | Tom Lane |
---|---|
Тема | Re: [WIP] The relminxid addition, try 3 |
Дата | |
Msg-id | 17969.1148607972@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [WIP] The relminxid addition, try 3 (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: [WIP] The relminxid addition, try 3
|
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: