Re: error "can only drop stats once" brings down database

At Mon, 10 Jun 2024 15:13:16 +0000, Floris Van Nee  wrote in 
> > 
> > Nah, ignoring the double-drop error does not seem right to me.
> > Wouldn't it make the most sense to ensure that the stats are dropped on the
> > standby instead on the first DROP replayed even if there are still references
> > to it hold, making sure that the stats entry with this OID is gone before
> > reusing it after wraparound?
> 
> Agree it doesn't seem right to just ignore. However I don't believe we can just
> drop the stats entry on replay of the first drop, right? That's why all this logic
> with pgstat_request_entry_refs_gc was invented in the first place, to get
> backends to clean up their refs first. If we free it, backends can't see the
> 'dropped' attribute anymore. This can only be changed if the whole gc
> mechanism gets revamped to use a different mechanism to notify backends
> that their local reference in pgStatEntryRefHash is suddenly invalid. I doubt
> that's backpatchable. 
> 
> On primary this doesn't happen because it's guaranteed that 'drop stats' can
> only ever happen after a 'create stats' call. This is the thing that's different on
> a replica: it is possible to get 'drop stats' twice, without a 'create stats' in between.

We don't simply allow double-drop; instead, we permit this kind of
behavior only during recovery by signaling the redo-execution
functions with the parameter isRedo, like smgr_unlink().

> Thing is that even on primary there are already some edge cases that it handles
> explicitly (eg. the create-drop-create case where on the second 'create' the old stats
> entry hasn't been removed yet). If the create-drop-create has special logic to handle
> the case that the old entry still exists, why wouldn't the create-drop-drop case have
> the special handling as well?

The two things look completely different to me. The former is an
indisputably legit operation, but the latter is indisputably
illegitimate as internal logic.

> Andres, would you be able to chime in on this?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center