Re: pg14b2: FailedAssertion("_bt_posting_valid(nposting)", File: "nbtdedup.c", ...

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg14b2: FailedAssertion("_bt_posting_valid(nposting)", File: "nbtdedup.c", ...
Date: 2021-06-28 06:08:42
Message-ID: CAH2-WznTSLLA=7CEXMhUEJTx=zvZqOuJgjvVDRQ-ejOb7K3tcA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 27, 2021 at 6:47 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> I've just realized that this VM has a strange storage configuration.
>
> It's using LVM thin pools, which I don't use anywhere else.
> Someone else set this up, and I think I've literally never used pools before.
> Some time ago, the pool ran out of space, and I ran LVM repair on it.
> It seems very possible that's the issue.
> A latent problem might've been tickled by pg_upgrade --link.

Anything is possible, of course, but even if this is a bug in Postgres
it isn't particularly likely to be a bug in the nbtree code. We see
clear signs of general corruption here, which is apparently not
limited to the one page that you supplied to me privately -- since
AFAICT that's not the page that amcheck throws the error on.

> That said, the relevant table is the active "alarms" table, and it would've
> gotten plenty of DML with no issue for months running v13.

It might not have been visibly broken without assertions enabled,
though. I sprinkled nbtdedup.c with these _bt_posting_valid()
assertions just because it was easy. The assertions were bound to
catch some problem sooner or later, and had acceptable overhead.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2021-06-28 06:14:10 Re: Deadlock risk while inserting directly into partition?
Previous Message vignesh C 2021-06-28 05:32:44 Re: missing GRANT on pg_subscription columns