From: Floris Van Nee <florisvannee@Optiver.com>
To: Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>
CC: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
        Kyotaro Horiguchi
	<horikyota.ntt@gmail.com>,
        "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>,
        "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Thread-Topic: [External] Re: error "can only drop stats once" brings down
 database [External]
Thread-Index: 
 AQHaZC2BJX3cZ68Gf0SnR3ukCGL5orGGQZEwgALhs4CAAGv+AIAsEUZQgAHuzgCAAg6I8IABEKoAgAAWkICAAUFxAIAAGUIAgAAHhACAAGn2gIAABMQAgAHQRtCAArEdAIAAq52w
Date: Mon, 10 Jun 2024 15:13:16 +0000
Message-ID: <e6a0bc8861b64acabce57c88e8e2c029@Optiver.com>
References: <68430b1b76d44558b7b07ae8c69151f6@Optiver.com>
 <ZmE-qm8d9kfDfnMy@paquier.xyz>
 <ZmFRlwr/53/tXqxn@ip-10-97-1-34.eu-west-3.compute.internal>
 <20240607.101540.1972690976596948719.horikyota.ntt@gmail.com>
 <ZmJ0bBODm6AitiC3@paquier.xyz>
 <20240607031258.l4fcpvulo3uee5g6@awork3.anarazel.de>
 <ZmLTneAb+EaZMS9A@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZmLXnAtRSUudsFqg@paquier.xyz> <2cb577e176774caca28c724898768a38@Optiver.com>
 <ZmafJO3lpMjbyHXv@paquier.xyz>
In-Reply-To: <ZmafJO3lpMjbyHXv@paquier.xyz>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: error "can only drop stats once" brings down database
Archived-At: 
 <https://www.postgresql.org/message-id/e6a0bc8861b64acabce57c88e8e2c029%40Optiver.com>
Precedence: bulk

>=20
> 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 t=
he
> standby instead on the first DROP replayed even if there are still refere=
nces
> 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 thi=
s 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 th=
e
'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 dou=
bt
that's backpatchable.=20

On primary this doesn't happen because it's guaranteed that 'drop stats' ca=
n
only ever happen after a 'create stats' call. This is the thing that's diff=
erent on
a replica: it is possible to get 'drop stats' twice, without a 'create stat=
s' in between.
Thing is that even on primary there are already some edge cases that it han=
dles
explicitly (eg. the create-drop-create case where on the second 'create' th=
e 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?

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

-Floris