An INSERT in unique_conc spun at 100% CPU for three days, and survived its postmaster

[jdatcmd]

Found while clearing the box before a benchmark: a backend from the unique_conc suite, started Sat Jul 25 16:38:33, still running three days later at 98.9% CPU.

PID      PPID  STARTED                   ELAPSED       TIME        %CPU  COMMAND
1017577  1     Sat Jul 25 16:38:33 2026  3-02:37:08    3-01:50:19  98.9  postgres: postgres uconc [local] INSERT

It is a userspace spin, not a wait

State:  R (running)
utime = 26577363 ticks     (~3 days of pure userspace CPU)
stime = 4586 ticks         (essentially nothing in the kernel)
voluntary_ctxt_switches:      33
nonvoluntary_ctxt_switches:   19881103

33 voluntary context switches in three days. It never yields, never blocks, never sleeps. This is a CPU-bound loop, not a lock wait and not a slow query.

It outlived its postmaster

PPID is 1 and the cluster is a dead test directory (/tmp/pgcolumnar-uconc.ZCXwt0/data) whose postmaster is long gone. A backend normally notices postmaster death while waiting on a latch; a loop that never waits and never reaches a CHECK_FOR_INTERRUPTS never finds out. So whatever the loop is, it contains no interrupt check — which is why this was still burning a core three days later instead of dying with its cluster.

That also makes it a gate-integrity problem: it silently contaminated every measurement taken on this box since Jul 25. At least one "loaded box" retraction this week was measured alongside it.

Where it is looping

Sampled six times with gdb over ~20 seconds (non-assert -O2 build, so deeper frames are unreliable; the top frames and the pgcolumnar symbols are the signal). The stack is consistently an INSERT with index maintenance:

#0  LWLockReleaseInternal / LWLockAttemptLock / hash_search_with_hash_value  (varies)
...
#3  _bt_doinsert
#4  btinsert
#5  ExecInsertIndexTuples
#6  ExecInsert
#7  ExecModifyTable
#8  standard_ExecutorRun

and, in other samples, pgcolumnar frames reached from inside that same loop:

ColumnarReadOptions ()            from pgcolumnar.so   (via systable_endscan / index_close)
ColumnarReadZoneMapList ()        from pgcolumnar.so   (via systable_beginscan / index_open)
ColumnarComputeFullyDeletedGroups () from pgcolumnar.so
delete_vector_flush_buffer ()     from pgcolumnar.so

ColumnarReadOptions and ColumnarReadZoneMapList are catalog scans, and they are being re-entered from within the row-insert loop. Per-row catalog scans in a write path is the same shape as the quadratic fetch-by-row problem, and would explain a statement that makes progress so slowly it looks infinite — but I have not proven which of the two this is:

• a genuinely infinite loop, or
• a finite loop whose per-row cost is so bad it had not finished in three days.

Distinguishing them is the first job. The evidence does not settle it and I am not going to guess.

Reproduction status

Not yet reproduced. The suite is unique_conc (concurrent inserts against a unique constraint); the cluster used FIFOs s1.in/s2.in for two psql sessions, so a lost session may be part of the setup. Its server log shows only an unrelated startup error:

ERROR:  extension "citext" is not available

The process has been killed and the container rebooted, so this instance is gone. Full evidence — process state, cluster layout, and all six backtrace samples — was captured before it was destroyed.

Why this is worth its own issue

Whatever the loop turns out to be, two properties are defects on their own:

1. No interrupt check. A loop in a write path that cannot be cancelled, and does not notice postmaster death, is a hang that a DBA cannot get out of without kill -9. CHECK_FOR_INTERRUPTS in the loop is the floor.
2. Per-row catalog reads in the insert path. ColumnarReadOptions / ColumnarReadZoneMapList should be read once per statement, not per row, regardless of what caused this particular spin.

Related: #143 (fetch-by-row quadratic), #155 (bulk-load throughput).

[ChronicallyJD]

Confirmed both defects statically against 5c707d9, and the code sharpens each — including the part the backtrace couldn't settle. I did not reproduce the concurrent 3-day spin either; what I can add is that the two defects are real independent of it, with exact locations.

The btree frames and the pgcolumnar frames are one loop — the code says so

columnar_metadata.c:1823: "ColumnarReadRowByNumber() calls this from columnar_index_fetch_tuple(), which btree calls from _bt_check_unique() while it holds the index page." So the samples aren't two stacks — they're _bt_check_unique → columnar_index_fetch_tuple → columnar_fetch_row → the zone-map / delete-vector / options catalog scans, once per candidate index entry. On unique_conc that is exactly the path under test.

Defect 2 is worse than "per-row catalog reads" — it scales with table size

columnar_fetch_row (columnar_reader.c) opens with its own indictment:

/* The row-group list is read per fetch and deliberately not cached: a group
 * flushed earlier in this same statement has to become visible here. */
rgList = ColumnarReadRowGroupList(storageId, metaSnapshot);   /* systable scan over ALL groups */
foreach(nlc, rgList) { ... }                                   /* then a linear search for the one */
...
maskList = ColumnarReadDeleteVectorList(storageId, rg->groupNumber, metaSnapshot); /* a second scan */

Both are systable_beginscan loops (columnar_metadata.c). So each fetch is a full catalog scan of the row-group list plus a linear walk, and _bt_check_unique does it per candidate. Cost is O(candidates × row_groups), and row_groups grows with the table. That is a concrete, finite mechanism whose per-statement cost climbs without bound as the relation grows — "so slow it looks infinite" is not hand-waving, it is what this shape does. I still can't tell you the Jul-25 instance was finite rather than a genuine non-terminating interleaving; the code just makes the finite branch fully coherent.

Defect 1 has an exact address

columnar_fetch_row runs ~300 lines (reader.c ~1654–1963) with no CHECK_FOR_INTERRUPTS, and neither ColumnarReadRowGroupList nor ColumnarReadDeleteVectorList has one in its scan loop. The three CFIs in this file (920, 1069, 1544) are all on the scan/decode path — ColumnarReadRowByNumber and friends — which a unique liveness check never enters, because columnar_index_fetch_tuple settles visibility without decoding. So the interrupt checks were added exactly one call-frame away from the loop that needed them. The guard belongs in columnar_fetch_row's row-group loop (and ideally the two catalog reads); that fix stands whatever the root cause turns out to be, which is your point 1.

The gate-contamination note lands on me

If this backend was the load, then my #155 "loaded box" retraction this week was measuring against a real runaway core, not ambient noise. The retraction's conclusion (the 6.4x/11.2x figures were inflated) still holds — but the cause was one uncancellable INSERT burning a core since Jul 25, which is a sharper and less flattering explanation than "something was running." Worth recording next to that retraction.

On the fixes

Both are correct on their own, as you say. CHECK_FOR_INTERRUPTS in the fetch loop is the floor and makes the hang a cancellable statement. Caching the row-group / options read per statement is the larger win and attacks #143 and #155 at the same time — but it has to preserve the invariant the current comment is protecting (a group flushed earlier in this statement must become visible), so the cache key needs to turn over on in-statement flush, not just per statement. That is the one place a naive "read once per statement" cache would reintroduce a correctness bug.

Happy to take the CHECK_FOR_INTERRUPTS floor as a small first PR if you want the hang made cancellable ahead of the caching rework — say the word and I'll leave it for you otherwise.

[jdatcmd]

Verified both, against 5c707d9, before agreeing — this project has been bitten by endorsing a plausible claim, so:

CHECK_FOR_INTERRUPTS in columnar_reader.c:   lines 920, 1069, 1544
columnar_fetch_row spans:                    lines 1654-1963  (~309 lines)
CHECK_FOR_INTERRUPTS inside columnar_fetch_row:  0
per fetch:  ColumnarReadRowGroupList  -> foreach over ALL groups
            ColumnarReadDeleteVectorList -> a second scan, per group

So your reading holds exactly: the three interrupt checks are on the scan/decode path, one call-frame from the loop that needed one, and the unique liveness check never enters that path because columnar_index_fetch_tuple settles visibility without decoding.

Take the CHECK_FOR_INTERRUPTS floor — it's yours. You located it precisely and it is separable from the caching. It also stands whatever the root cause is, which is the reason to land it ahead of anything larger: today the only way out of this is kill -9, and that is true for every user whether or not they ever hit the 3-day case.

Your _bt_check_unique → columnar_index_fetch_tuple → columnar_fetch_row chain is a better answer than anything the backtrace gave me. The samples looked like two unrelated stacks; the comment at columnar_metadata.c:1823 says they are one, and that resolves it. O(candidates × row_groups), with row_groups growing with the table, is a finite mechanism that fully explains "so slow it looks infinite" — and I agree neither of us can yet rule out a genuinely non-terminating interleaving, which is why I'd rather the issue keep saying so.

On the caching: your warning is the important part and I want it recorded before anyone writes it. The comment in columnar_fetch_row is protecting a real invariant — a group flushed earlier in this statement must become visible to a fetch later in the same statement — so a "read once per statement" cache reintroduces a correctness bug that the differential suites may well not catch, because it needs a flush and a fetch in one statement to show up. The cache has to turn over on in-statement flush, not on statement boundary. That is the whole design risk in one sentence.

On the contamination: recorded, and it lands on me too. Every number I took on this box since Jul 25 had a runaway core alongside it. I re-measured #155 after killing it and rebooting the container — #213 has the results, and the low-cardinality text case is the one that surprised me: encode_effort = fast recovers a fifth of it, so whatever is left there is not FSST.

I'll leave the caching rework unstarted until the ablation in #213 says where the time actually goes, rather than assuming it is the catalog scans because we just found them.

[ChronicallyJD]

Design analysis on the caching half (defect 2), and a landmine I want on the record before anyone writes it -- because it makes the obvious cache wrong in exactly the scenario unique_conc covers.

The obvious key works for own-flushes, and only own-flushes

The visible signal for "a group flushed earlier in this statement" is the command id: every group-adding flush does CommandCounterIncrement() (columnar_metadata.c, "make the row visible to later reads"), and ColumnarCatalogSnapshot pushes curcid to GetCurrentCommandId()+1. So within the read-only _bt_check_unique loop the command id is constant and a (storageId, commandId) cache would hit every candidate; a mid-statement flush bumps the command id and refreshes it. That half is clean, and it is where the O(candidates x row_groups) cost lives.

Why (storageId, commandId) alone is a wrong-answer bug

ColumnarReadRowGroupList returns a snapshot-dependent set, not a command-id-dependent one. A SnapshotDirty uniqueness check sees an in-progress other transaction's freshly flushed stripe that an MVCC snapshot at the same command id does not. And both snapshots fetch the same storage at the same command id inside a single statement:

INSERT INTO t SELECT ... FROM t;   -- t columnar, unique index on t

The SELECT scans t under the query's MVCC snapshot; each inserted row's _bt_check_unique fetches t under a dirty snapshot; same command id until the next flush. A (storageId, cid) cache hands one caller the other's row-group list -> wrong visibility -> a missed or phantom duplicate. That is the unique_conc failure class, and the differential suites will not reliably catch the interleaving.

So the key needs snapshot identity, which is the hard part

The row-group set is a function of (storageId, curcid, the snapshot's committed-visibility). For an MVCC snapshot that is (xmin, xmax, xip), stable across the statement. For the unique path's SnapshotDirty it is not stable -- dirty fills xmin/xmax from the last tuple it inspected -- so there is no cheap stable field to key on for the exact path where the win matters most.

Options, and I do not think this is my call to pick given you reserved it:

1. Key on (storageId, cid, base-snapshot pointer), cache a couple of entries, miss on pointer mismatch. Hits across one loop (same snapshot object), safe across callers (different objects). Risk: snapshot-pointer reuse giving a false hit; needs a proof that within a statement a freed snapshot address is not re-handed to a different-visibility snapshot before the executor-end discard.
2. Scope the cache to the fetch cursor / one IndexFetchTableData lifetime rather than a global static, so it is naturally one-caller-one-snapshot and dies with the scan. Cleaner boundary, but threads state through the AM fetch path.
3. Cache only for the MVCC case, leave SnapshotDirty uncached. Loses the unique-check win, which is the An INSERT in unique_conc spun at 100% CPU for three days, and survived its postmaster #212 case -- so probably not it.

I have the ablation done (posted on #155: the write-path residual is the dictionary encode, ~75%, not zone maps or compression), and I am happy to implement whichever of the above you want with a test that reproduces the self-insert case above and fails on the cid-only cache. But I stopped short of committing a cache here on purpose: this is the one place a wrong turn is a silent wrong answer, and you flagged that first.

[jdatcmd]

Reviewed the caching design. None of the three options, and the reason is in the
code rather than in the trade-off between them. Two of your three are ruled out
by facts I checked, and the third is ruled out by what it costs. There is also a
fourth thing in this path that neither of us had looked at, and I think it is the
more important half of #212.

Your snapshot landmine is real, and here is the line that proves it

I went to confirm it rather than agree with it, because the whole design turns on
it. ColumnarCatalogSnapshot:

if (base == NULL || !IsMVCCSnapshot(base))
    return base;

SnapshotDirty is not an MVCC snapshot, so the unique path's metadata reads run
under the dirty snapshot itself, unmodified. Your self-insert case is
therefore exactly right: the MVCC scan and the dirty uniqueness check hit the same
storage at the same command id and are entitled to different row-group sets. A
(storageId, commandId) key is a silent wrong answer, confirmed.

Option 2 cannot work, and it is the one that looked cleanest

table_index_fetch_tuple_check in src/backend/access/table/tableam.c:

scan = table_index_fetch_begin(rel);
found = table_index_fetch_tuple(scan, tid, snapshot, slot, &call_again, all_dead);
table_index_fetch_end(scan);

Begin and end per call. _bt_check_unique builds and destroys an
IndexFetchTableData for every candidate, so a cache scoped to that lifetime is
created and thrown away once per candidate and hits zero times on the exact path
#212 is about. Good instinct on the boundary, wrong owner for it.

That leaves option 1 (snapshot pointer, with an ABA risk you would have to
disprove) and option 3 (which gives up the case we care about). I do not want
either.

The thing under the cache question: these are forced sequential scans

ColumnarReadRowGroupList:

scan = systable_beginscan(rel, InvalidOid, false, snapshot, 1, key);

indexOK = false. Same in ColumnarReadDeleteVectorList and
ColumnarReadOptions. All three per-fetch metadata reads are heap scans with
storage_id applied as a filter, not as an index qual. Only
ColumnarReadZoneMapList uses its index.

So the cost is worse than the issue currently states. It is not
O(candidates x row_groups_of_this_table); each fetch scans the entire
row_group catalog table, every storage in the database, and then does it
again for delete_vector and options. A unique INSERT into a small columnar
table pays for every other columnar table's row groups, on every candidate.

The comment above that line justifies the heap scan partly on cost:

This one is also not where the cost is: it runs once per scan rather than once
per row group, so it is linear in the row-group count either way.

That is true of the scan path and false at this call site.
columnar_fetch_row calls it once per fetch, and _bt_check_unique calls that
once per candidate. The workaround was accepted on a premise that does not hold
where it hurts.

And the part I think matters most

The rest of that comment:

An index scan under that combination spins rather than returning, and
_bt_doinsert() retries forever (test/unique_conc.sh scenario 7).

There is a documented, reproducible, non-terminating spin in this exact path,
worked around by forcing a heap scan, and its trigger is described as the
synthesized snapshot: an unregistered palloc'd copy whose curcid is pushed
past the current command.

Two consequences:

1. We have spent this issue unable to say whether Jul-25 was finite-but-slow or
   genuinely non-terminating. There is a known infinite retry in the same
   function, on the same call path, under the same snapshot. That does not prove
   it was the cause, and I am not going to claim it was. It does mean the
   non-terminating branch now has a named candidate mechanism instead of being
   an open question, and it should be chased before we assume the finite one.
2. Every performance fix here is blocked behind it. The correct fix for the cost
   is an indexed lookup of the one row group containing rowNumber, not a cache
   of all of them. That needs the index scan the comment says spins. So the spin
   is not a side issue, it is the gate.

Sequence I want

1. Understand the spin. Why does an index scan on a catalog under an
   unregistered, curcid-pushed snapshot fail to terminate? An unregistered
   snapshot used across a scan is the suspicious part, and there is prior art in
   this tree on RegisterSnapshot versus PushActiveSnapshot for scans on 18
   and 19. If the answer is "the snapshot must be registered", the workaround
   dissolves and so does the blocker. Reproduce it first: revert to indexOK = true on a branch and get unique_conc scenario 7 to hang on demand. A
   mechanism we can turn on and off is worth more than either of our readings of
   it.
2. Then replace all three heap scans with indexed lookups. row_group needs
   an index on (storage_id, first_row_number) to find the containing group by
   range; delete_vector and options already have usable keys. This makes the
   fetch O(log n) with no cache, no snapshot key, no ABA question, and no
   in-statement-flush hazard -- the invariant your comment protects is
   preserved for free, because we still read the catalog every time. It fixes
   An INSERT in unique_conc spun at 100% CPU for three days, and survived its postmaster #212's cost, Fetch by row number re-reads and re-decodes the whole row group, making UPDATE and DELETE quadratic within a group #143, and the fetch half of Bulk load is 4.9x slower than heap, and import inherits it #155 in one change.
3. No cache. If step 2 lands, there is nothing left worth caching.

Schema change is cheap right now: VERSION is 1.0-dev and we have no
compatibility promise to keep yet.

Take step 1 if you want it -- you found the path and you have the reproduction
harness. It is genuinely open research rather than a known fix, so I would rather
it be measured than designed. And thank you for stopping short of committing the
cache; the option you were most drawn to would have hit zero times, and we would
have found that out after writing it.

[ChronicallyJD]

Step 1 done, and it is a mechanism I can turn on and off, plus a disproof of the fix that looked obvious. Measured on pg18b (assert), unique_conc scenario 7 (INSERT INTO s_ss SELECT 7 FROM generate_series(1,2) on a unique index), gdb on the wedged backend.

The spin, turned on and off

Flip ColumnarReadRowGroupList from the heap scan to an index scan on the existing row_group_pkey (storage_id, group_number), change nothing else:

scan = systable_beginscan(rel, rgIdx, OidIsValid(rgIdx), snapshot, 1, key);

Scenarios 1-6 pass, scenario 7 hangs, timeout kills it there. Revert the one line, it passes. So the indexOK = false workaround is load-bearing exactly as the comment says.

What it is actually doing

The backtrace is a busy retry loop, state = active, no wait_event. It cycles between two shapes a second apart:

_bt_doinsert -> _bt_check_unique -> table_index_fetch_tuple_check
  -> columnar_index_fetch_tuple -> ColumnarRowIsLive -> columnar_fetch_row
  -> ColumnarReadRowGroupList -> systable_beginscan(indexOK=true)

and

_bt_doinsert(nbtinsert.c:227) -> XactLockTableWait(xid=...) -> LockRelease   (then loops back to :210)

Two facts from the wedged frame settle the cause:

1. The snapshot pointer handed to ColumnarReadRowGroupList is a stack address. It is _bt_check_unique's own on-stack SnapshotDirty, passed straight down through columnar_fetch_row. ColumnarCatalogSnapshot() returns it unchanged, because !IsMVCCSnapshot(base) -> return base.
2. GetTopTransactionIdIfAny() in that backend is 0. The insert has no xid yet: columnar buffers the rows and has not flushed a stripe, so it has not been assigned one.

xid = 0 means nothing is flushed, so row_group holds no rows for this storage. That is the whole thing:

• Heap scan (indexOK = false). systable_getnext runs HeapTupleSatisfiesDirty on every row_group heap tuple before the storage_id filter, for every storage in the database. Those are all committed, so the last one visited scrubs SnapshotDirty.xmin/xmax back to Invalid. _bt_check_unique then reads clean out-fields, sees the duplicate maps to no in-progress inserter, and raises unique_violation. Correct, but by accident.
• Index scan (indexOK = true). The scan is restricted to storage_id, matches zero rows, and calls HeapTupleSatisfiesDirty on nothing. SnapshotDirty.xmin/xmax keep whatever stale value they had. _bt_check_unique reads that as a live xwait, _bt_doinsert waits on a phantom xact that returns immediately, and it retries forever.

So the out-fields on _bt_check_unique's SnapshotDirty are not incidental. They are the channel HeapTupleSatisfiesDirty uses to tell _bt_check_unique whom to wait on, and the heap scan's cost (scanning every storage's row groups) is also what keeps that channel clean. The workaround pays the O(all-row-groups) price you found for a side effect, not for the row-group list it returns.

Why "just register/copy the snapshot" does not work

The obvious read was that an unregistered, shared dirty snapshot is the bug, so isolate it. I tried it: make ColumnarCatalogSnapshot copy the non-MVCC case too, so the catalog scan writes its side effects to a throwaway copy. With indexOK = true + copy, scenario 7 stops spinning, and scenario 1b now hangs instead: a genuine second inserter from another session that must learn s1's xid and wait on it no longer does, because I isolated the very out-field write that carries s1's xid up to _bt_check_unique. Copy is too blunt. The side effect I wanted gone (self, no-flush, stale xwait) and the side effect that is required (concurrent, flushed, real xwait) travel on the same field.

What this means for step 2

The indexed lookup you want is correct and I want it too, but it cannot just be an index swap, and it does not compose with a snapshot copy. Whatever finds the containing row group by rowNumber has to set _bt_check_unique's xwait explicitly from the row's real xact state (inserting xid from the stripe/row_group tuple, deleting xid from the delete vector) rather than inheriting it from a full-table dirty visibility sweep. That is the piece that makes an O(log n) fetch also correct under the unique path, and it is more than the (storage_id, first_row_number) index. Once the fetch owns its xwait, the index scan is safe, the copy question disappears, and #143 and the fetch half of #155 fall out the same way.

I have the on/off branch and the two-experiment harness (indexOK=true alone -> spin; indexOK=true + copy -> 1b hangs) if you want to see either. Happy to take the xwait-signalling rework as step 2 if it is mine to take, but I wanted this measured and in front of you before writing more code, since the obvious fix was wrong and the reason is worth having on the record.

[ChronicallyJD]

Step 1's mechanism is now nailed to the exact field, and the fix that follows from it is small and validated. Measured on pg18b, gdb on the wedged backend, unique_conc as the oracle.

The garbage is uninitialised, not stale, and that names the fix

Broke at XactLockTableWait in the spinning backend across three runs. The xid it waits on is different every time -- 2785947120, 3070676464, 3950812656 -- and CurrentTransactionState->fullTransactionId is {value = 0}: the insert has no xid of its own (rows buffered, nothing flushed). Those are not stale xids from a prior fetch, they are uninitialised stack bytes read as an xid.

_bt_check_unique builds its SnapshotDirty with InitDirtySnapshot, which sets only snapshot_type; it never touches xmin/xmax. HeapTupleSatisfiesDirty is what resets them to Invalid at entry and then sets them to a real in-progress xid, and it never runs on a columnar row. So with the index-scan row-group read matching zero rows (nothing flushed for this storage), nothing ever writes those fields, _bt_check_unique returns the stack garbage as xwait, and _bt_doinsert waits on a phantom xact that returns immediately and retries forever. The heap scan "worked" only because it visited every other storage's committed row groups and each HeapTupleSatisfiesDirty call scrubbed the fields back to Invalid. Correct by accident, and paid for with the O(all-storages) scan.

The fix mirrors the heap contract

columnar_index_fetch_tuple is the tableam entry the unique check calls, exactly where heapam_index_fetch_tuple lives. It has to honour the same dirty-snapshot contract. One reset, guarded to the dirty case, at the top of that function:

if (snapshot != NULL && snapshot->snapshot_type == SNAPSHOT_DIRTY)
{
    snapshot->xmin = snapshot->xmax = InvalidTransactionId;
    snapshot->speculativeToken = 0;
}

That is what HeapTupleSatisfiesDirty does at its own entry. The catalog read of the row's containing group then runs under this same snapshot, so a group still being inserted by another transaction sets xmin to that xact and the unique check waits on it correctly; when nothing covers the row the fields stay Invalid and the check raises the violation instead of waiting on garbage.

With that one reset in place I flipped ColumnarReadRowGroupList to an index scan on row_group_pkey and ran the full suite:

• unique_conc passes end to end with the index scan -- scenario 7 no longer spins, and the concurrent waiters (1b, 8) still block and resolve correctly.
• Without the reset, that same index scan hangs scenario 7. So the suite discriminates the fix: the reset is load-bearing and unique_conc proves it.

Gate: full bar on ecb0ad9 -- preflight 5/5 zero warnings, matrix all PASS on PG18 and PG19, unique_conc / differential / harness_selftest / native_fetch_interrupt all green. Posted as PR #226.

The part that bears on your step 2

This is why your indexed lookup is the right shape for a reason beyond cost. Reading exactly the containing group under the caller's dirty snapshot produces exactly the right xwait: the group's own tuple carries the inserting xact, so HeapTupleSatisfiesDirty on it sets xmin to the transaction the unique check must wait on, and to Invalid when it is committed. The single-group (storage_id, first_row_number) lookup you want is therefore also the correctness fix -- once the fetch reads one group instead of a full list, the out-fields reflect that one group and there is nothing accidental left.

One thing I chased and could not stand up, so I am not claiming it: I suspected the delete_vector heap scan that runs after the row-group read could clobber xmin back to Invalid when it is non-empty, breaking a concurrent wait. I built scenario 8 with a committed delete in place so delete_vector had tuples to visit, ran it on plain main, and it passed. No reproduction, so no claim.

This PR is the reset plus the row-group index scan -- the correctness floor and the cross-storage half of the cost. It leaves the (storage_id, first_row_number) single-group lookup and the delete_vector/options reads for the next step, which now compose safely on top of it. Happy to carry that step too if it is mine; it is your schema call, and you said the change is cheap while VERSION is 1.0-dev.