On Fri, Sep 2, 2022 at 6:51 PM Peter Geoghegan wrote:
> Yes -- nbtree VACUUM generally can cope quite well, even when the
> index is corrupt. It should mostly manage to do what is expected here,
> even with a misbehaving opclass, because it relies as little as
> possible on user-defined opclass co
On Fri, Sep 2, 2022 at 6:14 PM Michael Paquier wrote:
> This has been a problem for years, and still for years to come with
> libc updates. I am not much into this stuff, but does running VACUUM
> in this case help with the state of the index that used a past,
> now-invalid, collation (be it libc
On Fri, Sep 02, 2022 at 02:13:15PM -0700, Peter Geoghegan wrote:
> Postgres 14 commit 5b861baa55 added hardening to nbtree page deletion.
> This had the effect of making nbtree VACUUM robust against misbehaving
> operator classes -- we just LOG the problem and move on, without
> throwing an error.
On Fri, Sep 02, 2022 at 02:13:15PM -0700, Peter Geoghegan wrote:
> I think that this should be backpatched now, to protect users from
> particularly nasty problems that hitting the error eventually leads
> to.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Postgres 14 commit 5b861baa55 added hardening to nbtree page deletion.
This had the effect of making nbtree VACUUM robust against misbehaving
operator classes -- we just LOG the problem and move on, without
throwing an error. In practice a "misbehaving operator class" is often
a problem with collat
