On Tue, Oct 17, 2017 at 6:02 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > Robert Haas wrote: >> I haven't really followed this thread in depth, but I'm very nervous >> about the idea that we should ever be examining the raw-xmin of a >> tuple that has been marked HEAP_XMIN_FROZEN for anything other than >> forensic purposes. > > Yeah, me too. If you see another way to fix the problem, let's discuss > it.
Well, I guess what I don't understand is, suppose we have a HOT chain that looks like this, where [x,y] denotes a tuple with an xmin of x and an xmax of y. [a,b]->[b,c]->[c,d] If b is eligible to be frozen, then b is committed and all-visible, which means that the [a,b] tuple should be pruned altogether. IOW, I don't think that a non-root tuple should ever have a frozen xmin; if that happens, I think we've already screwed up. So I don't quite understand how this problem arises in the first place. I think that the way we are supposed to be guaranteeing this is to first prune the page and then freeze it. If we ever freeze without first pruning, I think that's a bug. Now it could be that the problem is that there's a race: after we prune the page, somehow the xmin horizon advances before we freeze. But that also seems like something that shouldn't happen - our notion of the freeze threshold should be frozen at the beginning of the scan and should not advance, and it should be prior to our freeze horizon, which could be allowed to advance but not retreat in the course of the scan. Apologies if this is stupid; please clue me on what I'm missing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers