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.98.2) (envelope-from ) id 1x8anB-00000001Ml0-0lbN for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Sep 2026 09:58:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1x8anA-00000008oHQ-1yNI for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Sep 2026 09:58:32 +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.98.2) (envelope-from ) id 1x8anA-00000008oHH-0pUy for pgsql-hackers@lists.postgresql.org; Mon, 21 Sep 2026 09:58:32 +0000 Received: from mail-wm2-x10.google.com ([2a00:1450:4864:31::10]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1x8an7-00000000TNB-3yJL for pgsql-hackers@lists.postgresql.org; Mon, 21 Sep 2026 09:58:31 +0000 Received: by mail-wm2-x10.google.com with SMTP id 5b1f17b1804b1-49b912d391aso18354915e9.2 for ; Mon, 21 Sep 2026 02:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789984709; x=1790589509; darn=lists.postgresql.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=SbzhJ2EUFF8g6FKCagsYmTcXcZm5nFLz1z/4MHatBYI=; b=J+t9XequACZflRYsLQ4ObT8QulwQ4V/zuBcVYQ9CUgB85YD5MwNgH57hoN0sZx1OJg di2UtHkPiittJjPtKvIMSNpeej4RufYfqTvcLcKEbY77CdXlqilCGEmWdS79sDJIKMAG 4c+XQLBhs/dNcLIfllwsrTRA2cKrC54C4UJQCK6P+gbfJwEQBIbutNsz12xAk+v6Vdw3 Lw/ogc9uJ8RuMdz32hu3GWKLEJ4tH4+h4hKRG9h+Ui568aSsQMTqWQ902PhjFShBCwqW mUpe9N7d0HUKJr/tiNUl1Kq4wG0sQ0xd9JwVuoJZGxgaVwmbwlt/MTsllHjgY6Hys8vu gZow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789984709; x=1790589509; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=SbzhJ2EUFF8g6FKCagsYmTcXcZm5nFLz1z/4MHatBYI=; b=QwAKwcwY7Mo6qCvV9XfKPO1JSKwbRi00fPPn8wlnKzexn4rcf+3vojbakVD/5RpK9m 3Mm8EyJdbpOLAJJIxKAnH3ygN0XBED+j87gWd0Qvtbya8oSGl4KftxmpJV/uxDTzJKU0 NubRfUi8M0MzAgOQknd5T//0MJUut2bpUFwBw9y65FKkdQo8ZjxTEVQfraDu3iAISj/N HwWdx1CgiBnJsB8muVOBQFzYDqxmqTdbcHp1QZSf8c/AEW8sBARDU2YjMvVXCtW+TZ37 DhydXj8b7U4XAn7EkUQ/tzeBHAUjVMKhryYIjgh7fao+DSU6tNOTUUnD3zzvY2i17uSz 16EA== X-Forwarded-Encrypted: i=1; AKwUvBynZYGXTGYNEYUanQChsq38iXvGFQ/dMoY2RLGMu589EHcjy0zhF4XXXStx7CpEQDkJeXPP950m7crnDuDZ@lists.postgresql.org X-Gm-Message-State: AFuF++nhTCdZ099fzTx6Xd9lF+Wrh7w/YeJim8Y6iWkzqcasLkJlfqxA DdpWJnos3HrzlAeN/ORbHqe+C8SUemPHQ5L584E+YhhhyLT2x2PYor30 X-Gm-Gg: AYBFou0BzogKq6wWe0B4Y8K8xnOG+cDCsxKSTxcuBBvCR19Tt1WFGdXLyfoVaxw/0Ej kJMzoAau2XL8/TvmxX1Zi+ADe20WO0tNDfdHRFyjKcDCiss1tH3YXwLOB2t5Fg5kcyWCAh9J9/d SI7FCwtiMeR7WLBY7CC1UUe7TpCxRMsLHESmPjE/qo1R37Hl/aRB+XJndAqp5xIqnXhPYESoKZM RjuZjaVs/EaQXnUGc7u75nXtwW13TiO1yOPqsLiEhw3jgvTWBliF/CiA260DtSpDeRmpPR0851l aEzizVLjFp6r4JtgyY0uMBSsbqjY3tFfCocducBls3DjlbJmv/ElBm7ZDNXccRb/q/xnE/S+9Fo DhBEVeqNo25N3XPNqiHKOI+reSz6rIS9I3dqnwA6USG5bRJ7NjTW/a1yboLrfTWOVDkmOaztDjY hHpGyTMFGoFpVAssofnX0bzz+kcWxOhLHBrYt3Ey0X9lyoPDgtX4ehas61GNL3GxkbeUgd9LoVe 9Sa4/5zobIVnW51kDZ7bMmktusTpvHv4C7NJATHIykxjajy7ORWle1lAmdjAw4dxZ0wlQ== X-Received: by 2002:a05:600c:4e4a:b0:49e:6e94:7cae with SMTP id 5b1f17b1804b1-49fc5741495mr139970935e9.28.1789984708808; Mon, 21 Sep 2026 02:58:28 -0700 (PDT) Received: from bdtpg (ec2-15-237-197-144.eu-west-3.compute.amazonaws.com. [15.237.197.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fcd068124sm212366545e9.3.2026.09.21.02.58.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2026 02:58:28 -0700 (PDT) Date: Mon, 21 Sep 2026 09:58:27 +0000 From: Bertrand Drouvot To: Michael Paquier Cc: shihao zhong , Jim Jones , pgsql-hackers Subject: Re: Add a permission check to pg_stat_get_backend_subxact() 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 Mon, Sep 14, 2026 at 04:06:04PM +0900, Michael Paquier wrote: > On Sat, Sep 12, 2026 at 08:43:28AM -0400, shihao zhong wrote: > > Thanks for committing that, I will not include 0001 in the following emails. > > Fixed the subxact_overflow -> subxact_overflowed, as that's > independent. > > > 1. The first test block ran as superuser, so the owner branch of > > HAS_PGSTAT_PERMISSIONS() was never exercised: with "userid" forced to > > InvalidOid the test still passed. The block now grants the test role > > membership in the session's role instead. With that, forcing userid > > to InvalidOid fails the test, and removing the checks fails the > > "unrelated role" block. > > > > 2. The doc paragraph above the per-backend table said the functions > > "return NULL", but activity/wait_event return " > privilege>" and the SRFs return no rows. Reworded. > > > > 3. Commit message: noted that processes owned by no role (autovacuum > > workers, WAL writer, ...) are now visible only to superusers and > > pg_read_all_stats, as in pg_stat_activity, and that no backpatch is > > done. > > That seems globally sensible, at quick glance. I am also adding > Bertrand Drouvot in CC to comment about this change, as he has worked > on three of these functions. > > @Bertrand, what do you think? pg_stat_io, pg_stat_wal and pg_stat_lock expose aggregate statistics without restrictions but as pg_stat_get_backend_io(), pg_stat_get_backend_wal() and pg_stat_get_backend_lock() expose the stats for a particular backend, I think the proposed patch makes sense. One thing I noticed while looking at this is that with stats_fetch_consistency = snapshot, pgstat_fetch_stat_backend_by_pid() could validate the PID and user from one backend while returning cumulative statistics cached for an older backend that used the same ProcNumber. The race is not introduced by this patch, but the new permission check makes it more relevant here. Worth to fix at the same time? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com