Re: HOT synced with HEAD - Mailing list pgsql-patches
From | Tom Lane |
---|---|
Subject | Re: HOT synced with HEAD |
Date | |
Msg-id | 16971.1189966614@sss.pgh.pa.us Whole thread Raw |
In response to | Re: HOT synced with HEAD ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
Responses |
Re: HOT synced with HEAD
("Pavan Deolasee" <pavan.deolasee@gmail.com>)
|
List | pgsql-patches |
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes: > On 9/16/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> BTW, I'm in process of taking out the separate HEAPTUPLE_DEAD_CHAIN >> return value from HeapTupleSatisfiesVacuum. >> > I agree. I myself suggested doing so earlier in the discussion (I actually > even removed this before I sent out the add-on patch last night, but then > reverted back because I realized at least it is required at one place) > The place where I thought its required is to avoid marking an index tuple > dead > even though the corresponding root tuple is dead and the root tuple was > HOT updated. But seems like you have already put in a different mechanism > to handle that. So we should be able to get rid of HEAPTUPLE_DEAD_CHAIN. Yeah, actually this depends in part on having HeapTupleIsHotUpdated include a check on XMIN_INVALID; otherwise testing that wouldn't be a full substitute for what tqual.c had been doing. Something else I was just looking at: in the pruning logic, SetRedirect and SetDead operations are done at the same time that we record them for the eventual WAL record creation, but SetUnused operations are postponed and only done at the end. This seems a bit odd/nonorthogonal. Furthermore it's costing extra code complexity: if you were to SetUnused immediately then you wouldn't need that bitmap thingy to prevent you from doing it twice. I think that the reason it's like that is probably because of the problem of potential multiple visits to a DEAD heap-only tuple, but it looks to me like that's not really an issue given the current form of the testing for aborted tuples, which I have as if (HeapTupleSatisfiesVacuum(tuple->t_data, global_xmin, buffer) == HEAPTUPLE_DEAD && !HeapTupleIsHotUpdated(tuple)) heap_prune_record_unused(nowunused, nunused, unusedbitmap, rootoffnum); ISTM that if HeapTupleIsHotUpdated is false, we could simply SetUnused immediately, because any potential chain members after this one must be dead too, and they'll get reaped by this same bit of code --- there is no need to preserve the chain. (The only case we're really covering here is XMIN_INVALID, and any later chain members must certainly be XMIN_INVALID as well.) When the HOT-chain is later followed, we'll detect chain break anyway, so I see no need to postpone clearing the item pointer. regards, tom lane
pgsql-patches by date: