Hi, On 2019-05-02 10:20:25 -0400, Robert Haas wrote: > On Tue, Apr 16, 2019 at 12:44 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > So after thinking about this a bit more ... > > 2. Act as if the tuple were still live, just as would've happened if the > > state didn't change till just after we looked instead of just before. > > > > Option #2 is a lot simpler and safer, and can be implemented as I > > suggested earlier, assuming we're all good with the assumption that > > heap_prepare_freeze_tuple isn't going to do anything bad. > > After studying this more carefully, I agree. You and Andres and > Alvaro are all correct, and I'm plain wrong. Thanks for explaining. > I have committed a patch that changes the logic as per your > suggestion, and also removes nleft_dead_tuples and nleft_dead_itemids.
It'd be good if somebody could make a pass over the safety mechanisms in heap_prepare_freeze_tuple(). I added them at some point, after a data corrupting bug related to freezing, but they really were more intended as a secondary layer of defense, rather than the primary one. My understanding is still that we assume that we never should reach heap_prepare_freeze_tuple() for something that is below the horizon, even after this change, right? Greetings, Andres Freund
