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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: michael(at)paquier(dot)xyz
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-25 00:22:48
Message-ID: 20240625.092248.1063552122181843294.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Mon, 17 Jun 2024 08:28:10 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Fri, Jun 14, 2024 at 09:37:35AM +0900, Michael Paquier wrote:
> > 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.
>
> This still sounds like a good idea after sleeping on it over the
> weekend. Please note that I am moving on with the problem on this
> thread where this has been reported, and that is the point of origin:
> https://www.postgresql.org/message-id/ZmvVudpT8z6hbY9t@paquier.xyz
>
> Let's continue the discussion there.

Is it something like this? I forgot the reason why this was excluded
from the vinal version, though.

https://www.postgresql.org/message-id/20201001.090722.322196928507744460.horikyota.ntt%40gmail.com

> Dshash scans are used for dropping and resetting stats entries. Entry
> dropping is performed in the following steps.
>
> (delete_current_stats_entry())
> - Drop the dshash entry (needs exlock of dshash partition).
>
> - If refcount of the stats entry body is already zero, free the memory
> immediately .
>
> - If not, set the "dropped" flag of the body. No lock is required
> because the "dropped" flag won't be even referred to by other
> backends until the next step is done.
>
> - Increment deletion count of the shared hash. (this is used as the
> "age" of local pointer cache hash (pgstat_cache).
>
> (get_stat_entry())
>
> - If dshash deletion count is different from the local cache age, scan
> over the local cache hash to find "dropped" entries.
>
> - Decrements refcount of the dropped entry and free the shared entry
> if it is no longer referenced. Apparently no lock is required.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2024-06-25 02:07:31 Re: BUG #18522: Wrong results with Merge Right Anti Join, inconsistent with Merge Anti Join
Previous Message Haifang Wang (Centific Technologies Inc) 2024-06-24 22:07:30 RE: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607