Peter Geoghegan on Twitter: "@cyberdemn @jkatz05 @PostgreSQL So probably nothing to do with REINDEX CONCURRENTLY, then?" / Twitter

Now that

14.1 is out, you have no excuse not to upgrade ;-) Take advantage of the awesome new multirange types. Writeup and a presentation that deploys multiranges! blog.crunchydata.com/blog/better-ra slideshare.net/jkatz05/build-

Quote Tweet

PostgreSQL

@PostgreSQL

Nov 11, 2021

News: PostgreSQL 14.1, 13.5, 12.9, 11.14, 10.19, and 9.6.24 Released! postgresql.org/about/news/pos

3

2

16

Related,

9.6 receives its last set of fixes today. If you're still on 9.6 (or older), you should seriously consider upgrading to a supported version. Like 14 ;-)

1

2

Replying to

and

That's exactly what we did about a month ago and ended up with a few dozen corrupted UNIQUE indexes after doing REINDEX CONCURRENTLY. :(

1

Replying to

and

:( but there’s a fix now!

1

Replying to

and

I'm not sure about that. There is a fix for parallel vacuum and for CIC with prepared transactions. But we neither vacuumed anything manually nor have max_prepared_transactions > 0. So it could be something else.

1

Replying to

and

Were they TOAST indexes? I know of an unfixed bug in REINDEX CONCURRENTLY with TOAST indexes.

1

Replying to

and

No, normal ones. Many of them are primary keys on integer/bigint. I only run reindexdb -a --concurrently right after major upgrade 9.6->14, with max_parallel_maintenance_workers=4 which finished successfully. The corruption was discovered only a week or two later.

2

1

Replying to

and

So probably nothing to do with REINDEX CONCURRENTLY, then?

9:48 PM · Nov 11, 2021Twitter Web App

Replying to

Do you see missing rows, or something else? What does pg_amcheck's --heapallindexed option say about the indexes? Can you tell us what you know on the mailing list?

Conversation