On Wed, Jun 8, 2016 at 6:31 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Jun 8, 2016 at 4:01 AM, Amit Kapila <amit.kapil...@gmail.com>
> > If we want to address both page level and tuple level inconsistencies, I
> > could see below possibility.
> > 1. An API that returns setof records containing a block that have
> > inconsistent vm bit, a block where visible page contains dead tuples
> > block where vm bit indicates frozen, but page contains non-frozen
> > Three separate block numbers are required in record to distinguish the
> > problem with block.
> > Signature of API will be something like:
> > pg_check_visibility_blocks(regclass, corrupt_vm_blkno OUT bigint,
> > corrupt_dead_blkno OUT bigint, corrupt_frozen_blkno OUT boolean) RETURNS
> > SETOF record
> I don't understand this,
This new API was to address Andres's concern of checking block level
inconsistency as we do in lazy_scan_heap. It returns set of inconsistent
> The function that just returned non-frozen TIDs on
> supposedly-frozen pages was simple. Now we're trying to redesign this
> into a general-purpose integrity checker on the eve of beta2, and I
> think that's a bad idea. We don't have time to figure that out, get
> consensus on it, and do it well, and I don't want to be stuck
> supporting something half-baked from now until eternity. Let's scale
> back our goals here to something that can realistically be done well
> in the time available.
> Here's my proposal:
> 1. You already implemented a function to find non-frozen tuples on
> supposedly all-frozen pages. Great.
> 2. Let's implement a second function to find dead tuples on supposedly
> all-visible pages.
> 3. And then let's call it good.
Your proposal sounds good, will send an updated patch, if there are no