From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: florisvannee@optiver.com
Cc: andres@anarazel.de
Cc: bertranddrouvot.pg@gmail.com
Cc: tgl@sss.pgh.pa.us
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: error "can only drop stats once" brings down database
Date: Tue, 25 Jun 2024 09:22:48 +0900 (JST)
Message-ID: <20240625.092248.1063552122181843294.horikyota.ntt@gmail.com> (raw)
In-Reply-To: <Zm91CpHheqXC_S_V@paquier.xyz>
References: <20240611.164457.1388765109177375375.horikyota.ntt@gmail.com>
<ZmuQz8IN6MpLxKs8@paquier.xyz>
<Zm91CpHheqXC_S_V@paquier.xyz>
At Mon, 17 Jun 2024 08:28:10 +0900, Michael Paquier <michael@paquier.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: horikyota.ntt@gmail.com, michael@paquier.xyz, florisvannee@optiver.com, andres@anarazel.de, bertranddrouvot.pg@gmail.com, tgl@sss.pgh.pa.us, pgsql-bugs@lists.postgresql.org
Subject: Re: error "can only drop stats once" brings down database
In-Reply-To: <20240625.092248.1063552122181843294.horikyota.ntt@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox