On Fri, May 31, 2013 at 3:45 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 05/31/2013 12:22 PM, Stephen Frost wrote:
>> Where I'm going with this whole thing is simply that I do worry a bit
>> about using a bitmap for freeze, or similar, information and not being
>> able to reconstruct that bitmap from the heap. Perhaps that's overly
>> paranoid, but, well, we also write the same data out to disk in multiple
>> places multiple times- some might call that paranoid too. ;)
>
> On the other hand, we could combine Heikki's proposal (epoch numbers in
> the page header) together with using the visibility map for pages we
> don't need to vacuum freeze, and get vastly better behavior without
> increasing corruption risk that I can see.
Yeah, I was thinking about that as well. In fact, under either
Heikki's proposal or Andres's proposal or my variants of either one of
them, anti-wraparound vacuums no longer need to scan all-visible
pages. Under Andres's proposal (and variants), all-visible pages are
ipso facto frozen and therefore need not be scanned for freezing. But
under Heikki's proposal (and variants), anti-wraparound vacuums only
need to remove dead tuples; freezing live ones is a no-op. And
all-visible pages don't contain any dead tuples, so we're right back
in the same place.[1]
Where things diverge a little is what you when an anti-wraparound scan
encounters a page that isn't all-visible and can't be marked
all-visible. Under the "XID epoch" family of proposals, we need to
truncate any dead tuples on the page to line pointers, and that's it.
Under the "treat all-visible as frozen" family of proposals, we *also*
need to do old-style freezing on any aged but live tuples on the page.So the "XID epoch" saves write I/O in this case,
becausewe don't
dirty pages or write WAL just because we see a tuple with a high XID
age. Only pages that contain actual dead tuples get dirtied.
So on further reflection, I'm not seeing any advantage to combining
the two proposals. The "XID epoch" approach has the complications of
requiring page format changes and consuming space on every page,
although I think I may have worked out a variant approach that will
avoid that (which no one has commented on, so maybe I'm
hallucinating). But in other respects it seems better all around.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
[1] I said upthread that Heikki's idea would require a separate freeze
map, but now I think I was wrong.