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 1x8fq5-00000001Q9u-2xaD for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Sep 2026 15:21:54 +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 1x8fq3-0000000A8So-3Atj for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Sep 2026 15:21:51 +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 1x8fq3-0000000A8Sg-1SlH for pgsql-hackers@lists.postgresql.org; Mon, 21 Sep 2026 15:21:51 +0000 Received: from lahtoruutu.iki.fi ([2a0b:5c81:1c1::37]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x8fq0-00000000W0L-12yR for pgsql-hackers@lists.postgresql.org; Mon, 21 Sep 2026 15:21:50 +0000 Received: from [10.0.2.15] (unknown [75.125.238.33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4hpRlg4f38z49Q4V; Mon, 21 Sep 2026 18:21:35 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1790004096; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aokYXMrg/CA7ZMetC6K6QrSpTULNIk7goPvK586zalk=; b=vBGAI4wbc+JpGYC/EP+7dczj/GZlv+vmlNIjZubnE/Lu2k79TYJm6Ln3cfwAiRo/J41U8t STnOtYpQiCvE4bAMEhb0wW3AyhHnhRifhmSMWU085rwo3xdE43GohKRWZujilmnKKjwmb1 HGNvo42M056l33wxkkDhxNGym8xkj7k192D8RiOF+zuHMbfOzLO4BDK31tGHdIdHl0ylXD QxAOf610d3O/2qR8e9y4noV1Fw7lutf8hdSxkqnLJYTeQa3uO38RF8g/nku+xvlDH2OwxU uc+VdCiovmc77kxYEF+IPphQAI0wCINyjdbIjzQo5knu7r3wDa6BSa9zk3ugig== ARC-Seal: i=1; a=rsa-sha256; d=iki.fi; s=lahtoruutu; cv=none; t=1790004096; b=ombzuGHcY79R3kRnwLk1v9p0IHtlh2b9sKebWggf3QmisZxMgTl3jrxdrk7Y40gbc+aEUs bRUlcxe3BcBzC0t/kD5ZyWJ1HSIXjn0kbd7gncKRg5GpOfXt2SW+tyhNRqPZo/JAZ25rSP vUjLUn+hlrcVHSXo15Ta+w09n63BW10HxaGOf0GSdGzheoL4eim3kvzPk8Wzi0lk71439N GOhKFIR1Z7h/WJHEV4q0thpV3BpkZLiWRwvV2OomRkeG5CjC+Z4M/YglOxcBFaeiUGDki3 JseRpPOc3afBbGSczS01G6gXOKr81DHWlyPfoa32PNaBDl8Htlp2IqQ8bANm6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1790004096; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aokYXMrg/CA7ZMetC6K6QrSpTULNIk7goPvK586zalk=; b=MkOGytYPN+nBPZPc4Vrofsi6xD1yrdKuHQWx8gVKolDy6CMS7KqBo0LQB+p1QrYlny65cX 7/NXXHcO0WwFvLzoCRBG4RRGpFr47wLdHPRz6dpA8jbXMa+nGez9Vv2cy6Ogo34fG91+/X Tqjo460Qq6V9MsqU0bEjHmUmdKI5UyPMLchOG4pxMMF+mHeHNN1ISwwy+nd6I/7ptRO2IH dNDfFwK1cn3oP/Ox/YDvC3PHcl0eg6CC9pcnIGoZVmiju4yCwrbM0njeETEQiMEXE03WGX xiXF/eyEdDofVKVIaj9U0eE8m39ZuGH6cv6/zh85ys+junq9swJ+OVKp5PTPOg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi Message-ID: <4050bb5e-e8d5-4cd1-a65c-3f710c807cb9@iki.fi> Date: Mon, 21 Sep 2026 18:21:30 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby To: Michael Paquier Cc: Naga Appani , pgsql-hackers@lists.postgresql.org, Noah Misch References: Content-Language: en-US From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 21/09/2026 10:30, Michael Paquier wrote: > On Mon, Sep 21, 2026 at 10:19:47AM +0300, Heikki Linnakangas wrote: >> Hmm, the window could be very long, there's no guarantee that you'll see a >> MULTIXACT_TRUNCATE_ID record any time soon. And after restart, it'll revert >> back to 0 again. If we can't get a reasonable value at startup, I wonder if >> we should just always show NULL in the standby. > > I'd like to think that we should just throw an ERROR in this case with > a ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE, similarly to a lot of the > WAL functions. NULL is useful when for example using such a function > with a JOIN on catalogs, when called for a lot of tuples, but that's > not the case here. That would disable pg_get_multixact_stats() in a standby altogether, but only the members-related fields (num_members, members_size) have this problem. So that would throw some babies out with the bathwater. It's a new function so we could still do it though, if that's what we want. Another idea is to add the oldestOffset field to the control file. I actually find it a little weird that we don't have it there already. But I'm uncomfortable making that change so late in the release cycle, just for this function, in particular because it would require a catversion bump. - Heikki