On Wed, Jun 8, 2016 at 11:39 AM, Andres Freund <
andres@anarazel.de> wrote:
>
> On 2016-06-08 10:04:56 +0530, Amit Kapila wrote:
> > On Tue, Jun 7, 2016 at 11:01 PM, Andres Freund <
andres@anarazel.de> wrote:>
> > > I think if we go with the pg_check_visibility approach, we should also
> > > copy the other consistency checks from vacuumlazy.c, given they can't
> > > easily be triggered.
> >
> > Are you referring to checks that are done in lazy_scan_heap() for each
> > block?
>
> Yes.
>
>
> > I think the meaning full checks in this context could be (a) page
> > is marked as visible, but corresponding vm is not marked. (b) page is
> > marked as all visible and has dead tuples. (c) vm bit indicates frozen, but
> > page contains non-frozen tuples.
>
> Yes.
>
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 and a block where vm bit indicates frozen, but page contains non-frozen tuples. 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
2. An API that provides information of non-frozen tuples on a frozen page
Signature of API:
CREATE FUNCTION pg_check_visibility_tuples(regclass, t_ctid OUT tid) RETURNS SETOF tid
This is same as what is present in current patch [1].
In this, user can use first API to find corrupt blocks if any and if further information is required, second API can be used.
Does that address your concern? If you, Robert and others are okay with above idea, then I will send an update patch.
