Re: Use read streams in pg_visibility

Hi,

On Sat, 31 Aug 2024 at 02:51, Noah Misch <noah(at)leadboat(dot)com> wrote:
>
> To read blocks 10 and 11, I would expect to initialize the struct with one of:
>
> { .first=10, .nblocks=2 }
> { .first=10, .last_inclusive=11 }
> { .first=10, .last_exclusive=12 }
>
> With the patch's API, I would need {.first=10,.nblocks=12}. The struct field
> named "nblocks" behaves like a last_block_exclusive. Please either make the
> behavior an "nblocks" behavior or change the field name to replace the term
> "nblocks" with something matching the behavior. (I used longer field names in
> my examples here, to disambiguate those examples. It's okay if the final
> field names aren't those, as long as the field names and the behavior align.)

I decided to use 'current_blocknum' and 'last_exclusive'. I think
these are easier to understand and use.

> > Thanks for the information, I will check these. What I still do not
> > understand is how to make sure that only the second block is processed
> > and the first one is skipped. pg_check_visible() and pg_check_frozen()
> > returns TIDs that cause corruption in the visibility map, there is no
> > information about block numbers.
>
> I see what you're saying. collect_corrupt_items() needs a corrupt table to
> report anything; all corruption-free tables get the same output. Testing this
> would need extra C code or techniques like corrupt_page_checksum() to create
> the corrupt state. That wouldn't be a bad thing to have, but it's big enough
> that I'll consider it out of scope for $SUBJECT. With the callback change
> above, I'll be ready to push all this.

Thanks, updated patches are attached.

--
Regards,
Nazir Bilal Yavuz
Microsoft