On Mon, Jun 28, 2021 at 01:42:25PM -0700, Peter Geoghegan wrote:
> On Sun, Jun 27, 2021 at 11:08 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > > 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.
>
> Obviously nothing stops you from running amcheck on the original
> database that you're running in production. You won't need to have
> enabled assertions to catch the same problem that way. This seems like
> the best way to isolate the problem. I strongly suspect that it's the
> LVM issue for my own reasons: nothing changed during the Postgres 14
> cycle that seems truly related.
Sorry, but I didn't save the pre-upgrade cluster (just pg_dump).
For now, I moved the table out of the way and re-created it.
I could send you the whole relnode if you wanted to look more..
It seemed like almost any insert on the table caused it to crash.
BTW, on a copy of the v14 cluster, both vacuum and reindex also resolved the
issue (at least enough to avoid the crash).
--
Justin