On Wed, Oct 18, 2017 at 5:52 PM, Peter Geoghegan <pg@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
