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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: florisvannee(at)Optiver(dot)com
Cc: michael(at)paquier(dot)xyz, 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-11 07:44:57
Message-ID: 20240611.164457.1388765109177375375.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Mon, 10 Jun 2024 15:13:16 +0000, Floris Van Nee <florisvannee(at)Optiver(dot)com> wrote in
> >
> > 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.

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().

> 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?

The two things look completely different to me. The former is an
indisputably legit operation, but the latter is indisputably
illegitimate as internal logic.

> Andres, would you be able to chime in on this?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Lakhin 2024-06-11 08:00:01 Re: BUG #18483: Segmentation fault in tests modules
Previous Message Tender Wang 2024-06-11 07:44:21 Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943