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 1tY13w-001LlF-N1 for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Jan 2025 10:55:53 +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 1tY13u-00ABdX-Ao for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Jan 2025 10:55:50 +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 1tY13t-00ABdP-Vk for pgsql-hackers@lists.postgresql.org; Wed, 15 Jan 2025 10:55:50 +0000 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tY13r-000XHN-2s for pgsql-hackers@lists.postgresql.org; Wed, 15 Jan 2025 10:55:50 +0000 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-38a34e8410bso3157818f8f.2 for ; Wed, 15 Jan 2025 02:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736938546; x=1737543346; darn=lists.postgresql.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=f0efnAXKIJg++LeU397ZxU36y24+HDJ2P0qOoa+KZqk=; b=AaxohoK5ZuiU5d3DdgNETH2au2V4GgRXSMNq37blNpHgd2bBX3tn7tmcchXd9W4LTB Vh7/cKfYmc5bD3Vfi4O1GRAgrzOARIlUwOgKsV9zbO1xX+oqBfxccAZkzl0Most+RfOl SnIcrciN8s3SK+Gx3M9AExa8OaKhsCnzrgB2iB5E/XaU1KJuy+DgMMb74QgWRFbI3SDs p2KkTq1Ey+UL3n2R2YTCO9gyqUdrZoTgcrr4sV1gB/uplz44Bl/OQnIZG01Gq95G5Z8C CsD/CEGjh0ZzBx20W6glkqDfHrgiT2m+5YkeeqznYus/tJYKKeX1ViKOEcT5qVn+oOxX W0Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736938546; x=1737543346; h=in-reply-to:content-transfer-encoding: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=f0efnAXKIJg++LeU397ZxU36y24+HDJ2P0qOoa+KZqk=; b=jaBW/hAne1/XJ3t/3H8Cc1OTKP0ZPmDpRPDe7/dGXqu43DI1t6aSS4x6yvIrt9XYga sNQF1vK7fr4vq01WbLDaVIumsjzunjUtVJS+dXk1dO5Oy9KKu6txMBFbUNZtx5j/bUkB wyHMro83kovjyjVKG1NKB9nSMbGxhOieZqNu+HkGrU9ZYTZC1RqF1U3+cbnmju8MVO4Z wSmxkIXhaixSdbPtlIxhOK3N98R+iZ5Cq+2r3033NYTZck7aBwPn+PrGLCPKFfBu9Vpf rocm4wW+wqK/oSpv7aHtrqxDFV6geD3vEaDZCq+HOKbW01BXrwuO3DFc/eEdF/pLVbXd sLxQ== X-Forwarded-Encrypted: i=1; AJvYcCUSAkxdhuxRM1k5BDVB1nMBvsaXKABmcM/xpxC72A++HVrTn/9MUmJUJBFbGfdvWi9Sfy5J/0pjkslLO7qR@lists.postgresql.org X-Gm-Message-State: AOJu0Yzsmabqx+Fejd7rjTDGP1Q3df8Uv4ey3rvIceXIPI1TOCdzIdCV 8eIsmFzsII34CatttoMuCqwEU4QKT9a4xyuLnogpcOJ0lh/Z9bXv X-Gm-Gg: ASbGncsjxc8RsAL9pyXkN//rDJdPEtUslciJzDOjO2XOy4KmCjmZcsZaVzbc1nowjLT Tsbb3hKIsZbm+n4xI3uiobr+sAeNDgNuGjz02xKlyzEEZGSAsMxBxEAu964uDYq7TkHp6+Yd0DX ICJA312RYPY26MHw2rJUXSRP1GI08vsdi+6LhyeWjCNfmLqQfsPoBXq02m5cPSZ8dQbdN1snBw1 nIH5Fo/N8A8cZVyhmtT65e+URT96nKQZUtUlnyl9ldpGpIH07BH/UMTCSap9qS07SHagwNF9Vay 0JgOo7HOxAxr0rXSKVQ+u4jwwcqh4NDlA4VzyzqdddmSQmO540cucX+t4KZwsuRTk3fP8rUP/TT yR/Z36BQ= X-Google-Smtp-Source: AGHT+IFlOhtAMAsCB2dgrQR0p583G5oc5VrnRjaIxS5oKx2JJmihIGB4tTqpY1mDmRHaRf2QFHUGMQ== X-Received: by 2002:a05:6000:178a:b0:38a:4184:1529 with SMTP id ffacd0b85a97d-38a872d2aa5mr19251271f8f.12.1736938546459; Wed, 15 Jan 2025 02:55:46 -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-437c7540ae7sm18633655e9.33.2025.01.15.02.55.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jan 2025 02:55:46 -0800 (PST) Date: Wed, 15 Jan 2025 10:55:44 +0000 From: Bertrand Drouvot To: Michael Paquier Cc: Nazir Bilal Yavuz , Alvaro Herrera , Kyotaro Horiguchi , pgsql-hackers@lists.postgresql.org, Andres Freund Subject: Re: per backend I/O statistics Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Wed, Jan 15, 2025 at 06:27:22PM +0900, Michael Paquier wrote: > On Wed, Jan 15, 2025 at 08:30:20AM +0000, Bertrand Drouvot wrote: > > On Wed, Jan 15, 2025 at 11:03:54AM +0300, Nazir Bilal Yavuz wrote: > >> With this commit it may not be possible to count IOs in the critical > >> sections. I think the problem happens only if the local > >> PgStat_BackendPending entry is being created for the first time for > >> this backend in the critical section. > > > > Yeah, I encountered the exact same thing and mentioned it in [1] (see R1.). > > > > In [1] I did propose to use a new PendingBackendWalStats variable to "bypass" the > > pgstat_prep_backend_pending() usage. > > > > Michael mentioned in [2] that is not really consistent with the rest (what I > > agree with) and that "we should rethink a bit the way pending entries are > > retrieved". I did not think about it yet but that might be the way to > > go, thoughts? > > > > [1]: https://www.postgresql.org/message-id/Z3zqc4o09dM/Ezyz%40ip-10-97-1-34.eu-west-3.compute.internal > > [2]: https://www.postgresql.org/message-id/Z4dRlNuhSQ3hPPv2%40paquier.xyz > > My problem is that this is not only related to backend stats, but to > all variable-numbered stats kinds that require this behavior. Yeah, agree that it's better to have a "generic" solution. > A generic solution to the problem would be to allow > pgStatPendingContext to have MemoryContextAllowInCriticalSection() set > temporarily for the allocation of the pending data. > Perhaps not for all stats kinds, just for these where we're OK with > the potential memory footprint so we could have a flag in > PgStat_KindInfo. Giving to all stats kinds the responsibility to > allocate a pending entry beforehand outside a critical section is > another option, but that means going through different tweaks for all > stats kinds that require them. > > Andres, do you have any thoughts about that? Not sure what would be > your view on this matter. MemoryContextAllowInCriticalSection() for > stats kinds that allow the case would be OK for me I guess, Same here, that looks ok to me too. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com