On Mon, Jun 6, 2016 at 10:18 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas wrote: >> My gut feeling on this is to either do nothing or add a VACUUM option >> (not a GUC, not a reloption) called even_frozen_pages, default false. >> What is your opinion? > > +1 for that approach -- I thought that was already agreed weeks ago and > the only question was what to name that option. even_frozen_pages > sounds better than SCANALL, SCAN_ALL, FREEZE, FORCE (the other > options I saw proposed in that subthread), so +1 for that naming > too. > > I don't like doing nothing; that means that when we discover a bug we'll > have to tell users to rm a file whose name requires a complicated > catalog query to find out, so -1 for that.
So... I agree that it is definitely not good if we have to tell users to rm a file, but I am not quite sure how this new option would prevent us from having to say that? Here are some potential kinds of bugs we might have: 1. Sometimes, the all-frozen bit doesn't get set when it should. 2. Sometimes, the all-frozen bit gets sit when it shouldn't. 3. Some combination of (1) and (2), so that the VM fork can't be trusted in either direction. If (1) happens, removing the VM fork is not a good idea; what people will want to do is re-run a VACUUM FREEZE. If (2) or (3) happens, removing the VM fork might be a good idea, but it's not really clear that VACUUM (even_frozen_pages) will help much. For one thing, if there are actually unfrozen tuples on those pages and the clog pages which they reference are already gone or recycled, rerunning VACUUM on the table in any form might permanently lose data, or maybe it will just fail. If because of the nature of the bug you somehow know that case doesn't pertain, then I suppose the bug is that the tuple-level and page-level state is out of sync. VACUUM (even_frozen_pages) probably won't help with that much either, because VACUUM never clears the all-frozen bit without also clearing the all-visible bit, and that only if the page contains dead tuples, which in this case it probably doesn't. I'm intuitively sympathetic to the idea that we should have an option for this, but I can't figure out in what case we'd actually tell anyone to use it. It would be useful for the kinds of bugs listed above to have VACUUM (rebuild_vm) to blow away the VM fork and rebuild it, but that's different semantics than what we proposed for VACUUM (even_frozen_pages). And I'd be sort of inclined to handle that case by providing some other way to remove VM forks (like a new function in the pg_visibilitymap contrib module, maybe?) and then just tell people to run regular VACUUM afterwards, rather than putting the actual VM fork removal into VACUUM. -- 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
