On Tue, Jun 11, 2024 at 04:44:57PM +0900, Kyotaro Horiguchi wrote:
> 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().
Still, the case is different here, no? Recovery forgives unlinks as
long as we are in crash recovery, or consistency has not been reached
on a standby. This case is different: we are in a consistent state
and a backend on the standby still holds references to the stats entry
that is transparently reused after a wraparound.
I am wondering if we should tackle this problem by adding a notion of
"age" in the stats entries for what's stored in the central dshash and
in the hold copies in the backends, so as we dump the "age" of an
existing stats entry if we find out that it gets reused in a create
path. That requires some design and would not be backpatchable, but
it does not seem that invasive at quick glance (I had my eyes on this
code the full week). Other thoughts are welcome.
--
Michael
