Re: HOT documentation README
От | Tom Lane |
---|---|
Тема | Re: HOT documentation README |
Дата | |
Msg-id | 23910.1189615921@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: HOT documentation README ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
Ответы |
Re: HOT documentation README
|
Список | pgsql-patches |
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes: > On 9/12/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> XXX doesn't the above completely break the anti-wraparound guarantees? >> And why couldn't we avoid the problem by pruning the previous tuple, >> which is surely dead? > We preserve anti-wraparound guarantees by not letting the relfrozenxid > advance past the minimum of cut-off xid and xmin/xmax of not-yet-frozen > tuples. Given that this is required to address corner case of DEAD tuple > following a RD tuple, the final relfrozenxid would be very close to the > cut-off xid. Isn't it ? > We could have actually pruned the preceding RD tuples (as we do in > vacuum full), but we were worried about missing some corner case > where someone may still want to follow the chain from the RD tuple. This seems all wrong to me. We'd only be considering freezing a tuple whose xmin precedes the global xmin. If it has a predecessor, that predecessor has xmax equal to this one's xmin, therefore also preceding global xmin, therefore it would be seen as DEAD not RECENTLY_DEAD. So we should never need to freeze a tuple that isn't the start of its HOT chain. Also, if you find a DEAD tuple after a RECENTLY_DEAD one, you can certainly prune both, because what this tells you is that both tuples are in fact dead to all observers. regards, tom lane
В списке pgsql-patches по дате отправления: