Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDDLp-00GndI-VU for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Nov 2024 01:48:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tDDLn-009YVj-Tg for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Nov 2024 01:48:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDDLm-009YVb-KI for pgsql-hackers@lists.postgresql.org; Tue, 19 Nov 2024 01:48:20 +0000 Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDDLj-002fMo-HF for pgsql-hackers@lists.postgresql.org; Tue, 19 Nov 2024 01:48:18 +0000 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfhigh.phl.internal (Postfix) with ESMTP id 830E91140126; Mon, 18 Nov 2024 20:48:13 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Mon, 18 Nov 2024 20:48:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1731980893; x=1732067293; bh=Vy/YXrpZg5 pKunXE/B3ZT8LPjOSNfOsyRM2CktQFoSE=; b=lOFtbTGujYxxF329rY06Yey4z8 wtNbnSzqUHYRtynT8aY+bhyLQkBMhOs6+uSjr2p9D9r80CZhzIyoxdAj/nV4SmRt B+BRbwYqrkd0HVLACgxU5wWaN7GfcHNsRCetcZKsW5VD2Y20Pl8UKnKlSEXE3N6N VExt/oJcqF30bXIfjZpKUDBXAczGCfdfQMsVdX/T4teI3rM0MwYTt2XKMHRnjkWY UtgBW4EukWx56NpNedhtRtReR7YSgONl5X601EA2NwXL72zuhOwQBaYsDwGlk/6f SzRM3Y1MadMyI5ZDQH5jTNbqtxDMqPUvQ9bA/vzgWRLNLVoUAhPDY+D8e+vg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1731980893; x=1732067293; bh=Vy/YXrpZg5pKunXE/B3ZT8LPjOSNfOsyRM2 CktQFoSE=; b=Gu4B4aJcTIVbK7KSogxFDyc7GEzW0e3Xcgn9H2/k0IHg0K235g1 1Shcu9y6QEGsfzR+WMHnKAcve1Gnd23PEOCILff3BXkQMiXCLbT85tK5ZSbNx+dW dea2fyRkvDtNis1OHT7blAECRcSX+AS8edgC0bEN+0cfJVVprzGhz+s09PE8ASHn d8IpptjeD/r4ob0u1ssnLKPEdHbY1etms4IbhW2EtxuexKWZRbJg8E6kdc7o2+di juEuWQedIIHzG4H8EnRrRky+nb7mKohFooGfAXL/9nYm7Cv2vIGLh3rcjxbs5LqM lEQpcNWnkVxDmxyiwinOMUalrY5911a4Zww== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrfedugdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenfghrlhcuvffnffculdejtddmnecujfgurhepfffhvfevuffkfhgg tggujgesghdtreertddtvdenucfhrhhomhepofhitghhrggvlhcurfgrqhhuihgvrhcuoe hmihgthhgrvghlsehprghquhhivghrrdighiiiqeenucggtffrrghtthgvrhhnpeetleei fedufffhhfdtteelgeeggeffhfekueevteeigfduudevudetgfegiedvjeenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmihgthhgrvghlsehp rghquhhivghrrdighiiipdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhpohhuth dprhgtphhtthhopegsvghrthhrrghnuggurhhouhhvohhtrdhpghesghhmrghilhdrtgho mhdprhgtphhtthhopegshigrvhhuiiekudesghhmrghilhdrtghomhdprhgtphhtthhope grlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgpdhrtghpthhtohephhhorhhi khihohhtrgdrnhhtthesghhmrghilhdrtghomhdprhgtphhtthhopehpghhsqhhlqdhhrg gtkhgvrhhssehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: i0fe9450f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 18 Nov 2024 20:48:11 -0500 (EST) Date: Tue, 19 Nov 2024 10:47:53 +0900 From: Michael Paquier To: Bertrand Drouvot Cc: Nazir Bilal Yavuz , Alvaro Herrera , Kyotaro Horiguchi , pgsql-hackers@lists.postgresql.org Subject: Re: per backend I/O statistics Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NFyM3Idg+aKc5jcF" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --NFyM3Idg+aKc5jcF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 14, 2024 at 01:30:11PM +0000, Bertrand Drouvot wrote: > - change the arguments to false in the pgstat_drop_entry_internal() call = in=20 > pgstat_drop_all_entries() > - start the engine > - kill -9 postgres > - restart the engine >=20 > You'll see the assert failing due to the startup process. I don't think i= t is > doing something wrong though, just populating its backend stats. Do you h= ave > another view on it? It feels sad that we have to plug in the internals at this level for this particular case. Perhaps there is something to do with more callbacks. Or perhaps there is just no point in tracking the stats of auxiliary processes because we already have this data in the existing pg_stat_io already? > How would that work for someone doing "select * from pg_stat_get_backend_= io()"? >=20 > Do you mean copy/paste part of the code from pg_stat_get_activity() into > pg_stat_get_backend_io() to get the backend type? That sounds like an ide= a, > I'll have a look at it. I was under the impression that we should keep PgStat_Backend for the reset_timestamp part, but drop BackendType as it can be guessed from pg_stat_activity itself. For example a LATERAL to grab the current live stats of these backends. >> +typedef struct PgStat_PendingIO >>=20 >> Perhaps this part should use a separate structure named >> "BackendPendingIO"? The definition of the structure has to be in >> pgstat.h as this is the pending_size of the new stats kind. It looks >> like it would be cleaner to keep PgStat_PendingIO local to >> pgstat_io.c, and define PgStat_PendingIO based on >> PgStat_BackendPendingIO? >=20 > I see what you meean, what about simply "PgStat_BackendPending" in pgstat= =2Eh? That should be OK. >> Structurally, it may be cleaner to keep all the callbacks and the >> backend-I/O specific logic into a separate file, perhaps >> pgstat_io_backend.c or pgstat_backend_io? >=20 > Yeah, I was wondering the same. What about pgstat_backend.c (that would c= ontain > only one "section" dedicated to IO currently)? pgstat_backend.c looks good to me. Could there be other stats than just IO, actually? Perhaps not, just asking.. > - if the idea is to 1. record checkpointer stats, 2. do stuff in the back= end and > 3. check again the checkpointer stats then I don't think setting stats_fe= tch_consistency > to snapshot is needed at all. In fact it's quite the opposite as 1. and 3= =2E would > report the same values with stats_fetch_consistency set to 'snapshot' (if= done=20 > in the same transaction). Hmm. Not sure. It looks like you're right to treat this in a separate patch as it would exist for different reasons than the original proposal. -- Michael --NFyM3Idg+aKc5jcF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmc77kkACgkQnvQgOdby QH3J9Q/+NjMdHXJxHrrsDE6c9hjrccEBuELdnnqrvNq5tz4UMOWcN+JMOE+DHLYB oDYjnoybYoySBMpIVyG+IPnl46yjRYxInmKRWbxvlMo3/hgafx9yLjnm3KzlISGO t7+fM159D2ooJsrvwCqVhU3fK8OnccX7vj51LDXVchnTbGkuJKc9U6NKA4dM18iD UkEJdwMt6ahKYfwZSt9Q3yT3G5UO/spWRxuCJrNNAJM5LH1zRzSkMcl/pMKH5hJ6 WAoX1iLyi8k1v0EzDw7USrKCFnU6rKOtJc5sJSXIlxH6KUKNkJELfiqswTmuKyeV uKafVZAcsUxttLFUiVCvDc+/idJWwyfiqrd2mFRImqjPPsmKMoUnKy8NnaTFrNnA HONrqxFPUM5crxlpXxbWPZZsnHUX53KRADX6sxs/Oqmew2buDeOuHDE8QwAmmlm2 ZliRhdp4cO0xjC+fly/ItrV5vr8hzlIMuimucsGvcIcYSwq21lXaNcgJujR1nzAz LDjKi5BkkBaOd6Lh+CAZY9V7i5GOz2PG1X3SVgneJXy3E0KYV2J5oGR20cCYc0Ed OBq50WAMsVHs8nsMjecWVLfRKcdQTWwo7NxfnpO1S50DEMb7nmAxkiH5K/O47uEe HC7Wz85tHqNtkSImFvj58MAg8JUrdbkdrfQzS/WNhO7Hwn8+RB4= =GALY -----END PGP SIGNATURE----- --NFyM3Idg+aKc5jcF--