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 1tDlZC-0032HM-SP for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Nov 2024 14:20:26 +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 1tDlZB-006C7h-Gh for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Nov 2024 14:20:25 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDlZB-006C7X-62 for pgsql-hackers@lists.postgresql.org; Wed, 20 Nov 2024 14:20:25 +0000 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tDlZ8-002t7w-E1 for pgsql-hackers@lists.postgresql.org; Wed, 20 Nov 2024 14:20:23 +0000 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-431ac30d379so19681735e9.1 for ; Wed, 20 Nov 2024 06:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732112421; x=1732717221; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=q4u8IcDHluzdBFR1cdWnFTC21rtGMmwE3RLXmYRMKLY=; b=Fh9QMSleFPUh74rEdVZG9boLzdxSkVyA1Sh/H1oM+QILESu7nrjqYDxKj722lALLHu FffbHUbiFlkRhlgr+E3YW2LSQtEYq3a3WC4827Na5csJUd0k96cbTlLCjV5+BwuRYbSq CVDMSaOGKvkeEgmZLzwwdXzC3ElVMRs/G3EgPFWILW73HeUfOJ6ztMMDK7osIpeRJOBl 7emLJ812kVagb1GMKAnBN+ffSkL5LfMtiLhuxwKAiJn62pc9oCDIa10XmHatj+KD4AFI 6/ruQSUHbaVBkX7w22x9/ue7zbwSNG5U1LLAe4ANDOIgv1dVDujLV/5aiAJR71aALPUl IBag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732112421; x=1732717221; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=q4u8IcDHluzdBFR1cdWnFTC21rtGMmwE3RLXmYRMKLY=; b=GNeNo2sp8rfwcmUrpuc1Ha2CBddEh0ZelW8a6hzlEF8XhjU5SLaXJtQ+0a5/u/u2Yh HE5UQd4zzG2gHuKgZ31mvsV7T0pvWDVaI9uUytgd9B4U4o6PyF8XMGReCZie3DAMD1Ie Q5GWzBpL9YVu/wugXsWbLHHhkukqjCwHrtnWUlh4aYF5v+yzHu2YyW3hNduaegM5kwd1 9UBT4pvDZIfwYM8TAt5YThbeSK09jG96eTBemle/gHzAj8m18W+OQabmRLG0lxRBKPzr PGemGDBg8ePwgMls8jgqCuGyku0JK32opjzxvBpq+pf1jqkwkiDedAjU6oPdXSyKaMkp kBuQ== X-Forwarded-Encrypted: i=1; AJvYcCWST8xGjqu+A3ZH8pilOezgOeUhaP4psnU/AhWOkX2Y2erhclpP3T1Z3fIAk7jjpfffEINsgH3RZZPl/bMi@lists.postgresql.org X-Gm-Message-State: AOJu0Yzb66mbfWlTArWy4RWIF+2HbMZvifZ8FlGbhb14Gr7HlxscuqWW y4d8h4UlfNHcEu2XUXBSGwJ3yaPkwqJUU2893twvtaX696KPLdul X-Gm-Gg: ASbGncs17WX5Ql7+2AbfywOeui9pIfT3MfZUXplhFyN1OQo4cwCa/MTTJ4L1/AEvaO8 T8eVFn40iYlh8UnHxmk7vNsFqBAVR//pT0FEhdnCZ0zUAV+3Imd0XnO5C9ZUpTud1j6fvqLaXc/ qnjbIn7rvCfgywEdqwuzVK4aiwZn+9oxVUrT47gPv6WUqc48qZUjQMZrfHGnusQk1NMkeS1nEbl 2gP4vgifctFSOZrlPrUX5JIQDrk2QRzdUUJ/xFYRYwmKma2IbqKr12G4/aZpj0IgizVsoPbfizD K6SDGPWckWnhWwfq7YutVC45TFUoqCr8oAWdO8BOFWXJYLL4gLvqGMCBw9jk/eHW9Gb1hqZ/mC7 B X-Google-Smtp-Source: AGHT+IGOmo0Da+j/FGGvNBPP/xtGfp+di6cYY9MzrPTFkQTVOlZEhqh1susCLOwhj2M3qbHLhMk0mQ== X-Received: by 2002:a05:600c:1f93:b0:430:699b:7d22 with SMTP id 5b1f17b1804b1-4334f0172d4mr23306335e9.26.1732112420636; Wed, 20 Nov 2024 06:20:20 -0800 (PST) Received: from ip-10-97-1-34.eu-west-3.compute.internal (ec2-15-236-134-5.eu-west-3.compute.amazonaws.com. [15.236.134.5]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-433b463439esm20643195e9.31.2024.11.20.06.20.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Nov 2024 06:20:20 -0800 (PST) Date: Wed, 20 Nov 2024 14:20:18 +0000 From: Bertrand Drouvot To: Michael Paquier 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Wed, Nov 20, 2024 at 09:01:26AM +0900, Michael Paquier wrote: > On Tue, Nov 19, 2024 at 04:28:55PM +0000, Bertrand Drouvot wrote: > > So, for the startup process only, what about? > > > > - don't call pgstat_create_backend_stat() in pgstat_beinit()... > > - but call it in StartupXLOG() instead (after the stats are discarded or restored). > > > > That way we could get rid of the changes linked to the assertion and still handle > > the startup process particular case. Thoughts? > > Hmm. That may prove to be a good idea in the long-term. The startup > process is a specific path kicked in at a very early stage, so it is > also a bit weird that we'd try to insert statistics while we are going > to reset them anyway a bit later. Exactly. > That may also be relevant for > custom statistics, actually, especially if some calls happen in some > hook paths taken before the reset is done. This could happen for > injection point stats when loading it with shared_preload_libraries, > actually, if you load, attach or run a callback at this early stage. Right. I did not had in mind to go that far here (for the per backend stats needs). My idea was "just" to move the new pgstat_create_backend_stat() (which is related to per backend stats only) call at the right place in StartupXLOG() for the startup process only. As that's the startup process that will reset or restore the stats I think that makes sense. It looks like that what you have in mind is much more generic, what about: - Focus on this thread first and then move the call as proposed above - Think about a more generic idea later on (on the per-backend I/O stats is in). Thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com