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