Re: Tepid: selective index updates for heap relations - Mailing list pgsql-hackers

From Greg Burd
Subject Re: Tepid: selective index updates for heap relations
Date
Msg-id 3dc5d57e-6c77-4713-b97e-bf0a5a891226@app.fastmail.com
Whole thread
In response to Re: Tepid: selective index updates for heap relations  ("Greg Burd" <greg@burd.me>)
Responses Re: Tepid: selective index updates for heap relations
List pgsql-hackers
I should have checked and rebased before I posted v59, apologies.  Here's v60 which should be clean against
1c4b1de8885.

Also fixed the following oversights:

1. CLUSTER / VACUUM FULL data loss + index staleness on SIU tables — the heap rewrite left the stale
HEAP_INDEXED_UPDATEDbit on flattened tuples, so readers ran the staleness test against a now-meaningless inline bitmap
anddropped live rows (and returned nothing via index). Fixed by clearing the marker in reform_tuple. Hit any SIU table
aftera routine VACUUM FULL. 

2. amcheck heapallindexed false positive — its bloom-filter fingerprint of a flagged leaf TID never matched the plain
heapTID it re-derives, raising a spurious "lacks matching index tuple." Fixed by stripping the marker while
fingerprintingin verify_nbtree. 

3. Tooling
 - pageinspect 1.14 — bt_page_items now reports the real offset in ctid/htid (was showing an inflated offset) and adds
ahot_indexed column exposing the marker. 
 - Sentinel-safe strip — ItemPointerGetOffsetNumber/ItemPointerCompare strip bit 14 but leave the
SpecToken/MovedPartitionsoffset sentinels untouched (a self-inflicted regression caught during development). 


best.

-greg
Attachment

pgsql-hackers by date:

Previous
From: Hüseyin Demir
Date:
Subject: Re: Checkpoint replication slots later
Next
From: Scott Ray
Date:
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples