On Thu, Oct 28, 2021 at 2:50 AM David Rowley <dgrowleyml@gmail.com> wrote:
> I stared at that code for a while and didn't really see how it could
> be broken, unless if the atomics implementation on that machine were
> broken. Thomas and I had a look at that earlier and on his FreeBSD
> machine, it uses the arch-x64.h implementation of
> pg_atomic_fetch_add_u64_impl().
Thank you for going through that exercise. I now strongly doubt that
it's CREATE INDEX at all.
My suspicion is now falling on the snapshot scalability work. And some
interaction with VACUUM. Probably only with shared row locks and
concurrency. More on this later.
> We just get the same tid twice in the index. That's quite different
> from another value of "t" getting into the list of tids for '185050'.
FWIW I thought that it might have been possible for the index to
become even more corrupt, due to a lack of defensive measures inside
nbtree. But I now see that that can't have been it.
Apologies for the noise.
--
Peter Geoghegan