Re: index prefetching

Hi Peter,

This is a cool feature, and I like it. I spent some time catching up
on the thread and reviewing the code.

The core prefetch logic LGTM. I found a few issues elsewhere.

The GiST cleanup-lock fix appears to be incomplete on standbys.
gistvacuumpage() already accounts for the root changing from a leaf page
to an internal page while a scan holds a pin, but it only emits VACUUM
WAL when it actually deletes index tuples from a leaf page.

After a root split, a standby cursor may still hold a batch copied from
the old root leaf, along with a pin on the root buffer. VACUUM acquires
a cleanup lock on the now-internal root on the primary, but there is no
corresponding WAL record to enforce that interlock on the standby. Heap
cleanup and visibility map updates can therefore be replayed while the
cursor still holds the old batch. When the cursor resumes and checks
visibility for the remaining items, it can see the new all-visible bits,
skip the heap checks, and return entries for deleted tuples. The
necessary cleanup-lock barriers need to be WAL-logged even when there
are no tuple deletions.

There is also an inconsistency in the batch layout initialization
comments: relscan.h says the dynamic opaque area size is set in
ambeginscan, whereas spgrescan() explains that it must wait until
xs_want_itup is known.

While reviewing the code, I also found an unrelated issue in the
baseline's cmp_orderbyvals():
```c
else if (anulls[i] && bnulls[i])
return 0;
```

When both values for the current key are NULL, this ignores the
remaining sort keys. In a lossy KNN scan, that can make the executor
incorrectly conclude that the index-provided distances are exact and
return tuples in the wrong order. I suggest changing `return 0` to
`continue` so that the remaining keys are compared.