> On Mar 24, 2021, at 1:46 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> Mark,
>
> Here's a quick and very dirty sketch of what I think perhaps this
> logic could look like. This is pretty much untested and it might be
> buggy, but at least you can see whether we're thinking at all in the
> same direction.
Thanks! The attached patch addresses your comments here and in your prior email. In particular, this patch changes
thetuple visibility logic to not check tuples for which the inserting transaction aborted or is still in progress, and
tonot check toast for tuples deleted in transactions older than our transaction snapshot's xmin. A list of toasted
attributeswhich are safe to check is compiled per main table page during the scan of the page, then checked after the
bufferlock on the main page is released.
In the perhaps unusual case where verify_heapam() is called in a transaction which has also added tuples to the table
beingchecked, this patch's visibility logic chooses not to check such tuples. I'm on the fence about this choice, and
ammostly following your lead. I like that this decision maintains the invariant that we never check tuples which have
notyet been committed.
The patch includes a bit of refactoring. In the old code, heap_check() performed clog bounds checking on xmin and xmax
priorto calling check_tuple_header_and_visibilty(), but I think that's not such a great choice. If the tuple header is
garbledto have random bytes in the xmin and xmax fields, and we can detect that situation because other tuple header
fieldsare garbled in detectable ways, I'd rather get a report about the header being garbled than a report about the
xminor xmax being out of bounds. In the new code, the tuple header is checked first, then the visibility is checked,
thenthe tuple is checked against the current relation description, then the tuple attributes are checked. I think the
layoutis easier to follow, too.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
