Hello,
you are right it looks to be related, on our running system with connected
users such an issue happens not only on primary keys but also on other
(non-unique) indexes.
I've checked all indexes using amcheck:
select * from bt_index_check(index =>
'prematch.opportunities.pk_tabodds_idodds':
Thanks for the bug link, I haven't found it.
Ales
út 24. 5. 2022 v 21:58 odesílatel Thomas Munro
napsal:
> On Wed, May 25, 2022 at 6:17 AM Aleš Zelený wrote:
> > SELECT format('REINDEX SCHEMA CONCURRENTLY %I;', n.nspname)
>
> This may be related to bug #17485, discussed at:
>
>
> https://www.p
On Wed, May 25, 2022 at 6:17 AM Aleš Zelený wrote:
> SELECT format('REINDEX SCHEMA CONCURRENTLY %I;', n.nspname)
This may be related to bug #17485, discussed at:
https://www.postgresql.org/message-id/flat/17485-396609c6925b982d%40postgresql.org
Hello,
we have a problem with an index on a database we recently upgraded from
PG13 to Pg14.3 using pg_upgrade. After all the upgrade steps including
analyze in stages, we run "vacuumdb -Fvaz -j 8" and the user workload was
started afterward.
In order to get one of the Pg14 benefits (b-tree dedup
