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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: florisvannee(at)optiver(dot)com, andres(at)anarazel(dot)de, bertranddrouvot(dot)pg(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: error "can only drop stats once" brings down database
Date: 2024-06-14 00:37:35
Message-ID: ZmuQz8IN6MpLxKs8@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Jeff Davis 2024-06-14 04:25:30 JIT crash introduced by 6185c9737c with LLVM 14
Previous Message Tom Lane 2024-06-13 23:59:22 Re: BUG #18479: websearch_to_tsquery inconsistent behavior for german when using parentheses