On Wed, Oct 18, 2017 at 5:52 PM, Peter Geoghegan <p...@bowt.ie> wrote: > There is a race where we cannot prune the page, though. That's why we > had to revisit what I suppose was a tacit assumption, and address its > problems in the commit that started this thread (commit a5736bf7).
The commit message for a5736bf7 doesn't say anything about a race; it just claims that it is fixing traversal of half-frozen update chains, without making any reference to how such a thing as a half-frozen update chain came to exist in the first place. I think the commit that talks about that race condition is 20b65522. /me studies the problem for a while. What's bothering me about this is: how is cutoff_xid managing to be a new enough transaction ID for this to happen in the first place? The cutoff XID should certainly be older than anything any current snapshot can see, because it's computed using GetOldestXmin() -- which means that XIDs older than the cutoff can't still be running (except maybe if old_snapshot_threshold is set to a non-default value). And that means that the state of any tuple to which heap_prepare_freeze_tuple() does anything shouldn't be able to change between the time the HOT-prune is done and the time freezing is completed. To put that the other way around, an xmin or xmax that was still running when we did the HOT prune should also be too new to get frozen. -- 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
