>
> 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.
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?
Andres, would you be able to chime in on this?
-Floris
