On Fri, Jul 31, 2020 at 12:33 PM Andres Freund <and...@anarazel.de> wrote: > I'm not sure what I was thinking "back then", but right now I'd argue > that the best lock against vacuum isn't a SUE, but announcing the > correct ->xmin, so you can be sure that clog entries won't be yanked out > from under you. Potentially with the right flag sets to avoid old enough > tuples eing pruned.
Suppose we don't even do anything special in terms of advertising xmin. What can go wrong? To have a problem, we've got to be running concurrently with a vacuum that truncates clog. The clog truncation must happen before our XID lookups, but vacuum has to remove the XIDs from the heap before it can truncate. So we have to observe the XIDs before vacuum removes them, but then vacuum has to truncate before we look them up. But since we observe them and look them up while holding a ShareLock on the buffer, this seems impossible. What's the flaw in this argument? If we do need to do something special in terms of advertising xmin, how would you do it? Normally it happens by registering a snapshot, but here all we would have is an XID; specifically, the value of relfrozenxid that we observed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
