Re: BUG #17245: Index corruption involving deduplicated entries

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Kamigishi Rei <iijima(dot)yun(at)koumakan(dot)jp>, David Rowley <dgrowley(at)gmail(dot)com>, Herman verschooten <Herman(at)verschooten(dot)ne>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Herman verschooten <Herman(at)verschooten(dot)net>
Subject: Re: BUG #17245: Index corruption involving deduplicated entries
Date: 2021-10-28 20:31:51
Message-ID: CAH2-WzmKdDF-U1ELXs3=KuGnfAgQMjvPcUZahE9oS9C6nxgs7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Oct 28, 2021 at 2:50 AM David Rowley <dgrowleyml(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Munro 2021-10-28 20:59:14 Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Previous Message David G. Johnston 2021-10-28 17:30:52 Re: Error in 'FROM' function