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.96) (envelope-from ) id 1vyWOr-000BLP-0K for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Mar 2026 14:43:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vyWOp-005RH5-21 for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Mar 2026 14:43: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.96) (envelope-from ) id 1vyWOp-005Qxb-06 for pgsql-hackers@lists.postgresql.org; Fri, 06 Mar 2026 14:43:31 +0000 Received: from lahtoruutu.iki.fi ([185.185.170.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 1vyWOn-00000000mj6-1ofp for pgsql-hackers@lists.postgresql.org; Fri, 06 Mar 2026 14:43:30 +0000 Received: from [10.0.2.15] (unknown [130.41.208.2]) (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 4fS8KT0Z7sz49PtL; Fri, 06 Mar 2026 16:43:25 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1772808205; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nt+oTyyz8IhQZ85iBnY3gmiU2Hu7/Z7i9GvDqJ4QvfI=; b=HIjK2SSjzfcZyZdXXlwueQVCX1zkR0F/cnFDX8QVCuYesUCCN5H93kOoInpR8q6QDaSUqM wSTxU0xhlF42aTGez1J6VL3bm1yeFIcoCFEDbUNXd6aaap96WJpzyETtxPqoOWvGAQ1AQ6 oskcMeZktuTNouCfQ6N15IAE5h/kOS+R7hg0GE/wY0vn9CJqVbD5U348qVvTfHZfnWQ43/ 6yYVfqbatJk+U19jx8CAXJwq8eE94j/xsuPMr2fohS5xf2LHZF1GBqtMZDyJnCu7G3Xqme OUpSvz1O/9SL52d131fid4I07yxZXJRLUh99NqFAjGqEJ6q6HBHI7LqV1FPJ5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1772808205; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nt+oTyyz8IhQZ85iBnY3gmiU2Hu7/Z7i9GvDqJ4QvfI=; b=fPRLvBnfdParbj6W8IMEHRAfy0N5MTIz7vtyhPIQaSUCO2GKZ1dRnTG1JLKJZcPQGqrzkp J5i5pfkMr2H6JQyh/qSJImyfIFmn7/9aTx6XuYioQd4i3mL7PI+DXnI0+Dw+Ws4uLtWjY7 hdS81L9coYVrVvVbA+KdiSxeQLFi0jtj3FPtd8FBxfUMQRXjEY0xmtfwkYMnmZ5bcpll+V CCA9YsZE9VjXGLZubz5KMo2l4ELsAPaB9UwCfYYLe1K5+7SDHSFz0A3vR3C3NQOFZ0lt8b fkB1lfiNMU3dd1M5pqw492P/Ly6yiwAd0cZx7pu3/rnIkSUFxrOcFUQmB3SChA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Seal: i=1; a=rsa-sha256; d=iki.fi; s=lahtoruutu; cv=none; t=1772808205; b=R22fJmPkHtszkr/HpO9NVvz9L5pYjE5N8s8NWPKp4UNk2rjaILpZGBYS1RqUsfW/AFsZUW 3f/8P2yFFSRiSRW51o2Yvgn0tdOMLnc7G2mfvLB1NrpsC6xBHG0If/xXpUlDY1mXVy3gZ3 2kaPn4FTIRekvBInl2wtNCDMwton0s1EcKixCIZEo2nToijq0Yka/P8hqWQJWZYQF0XVxR nVT9+KseZK55EoDzoH8H4MLVOI0Ag1eEKPiNAQV5XKdN8ZT9VguYF8Ee0s0ldRWVSIEkv/ f6efU2QHED1CI/zFDoPMbrNhTupLn7YhSa+6L0y+40JDNn/PZ0CU9WpMJRBpJQ== Message-ID: Date: Fri, 6 Mar 2026 16:43:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Rework SLRU I/O errors handle To: Maxim Orlov , Postgres hackers 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 26/02/2026 16:26, Maxim Orlov wrote: > Beginning of the discussion is here [0]. > > Historically, the SLRU module was designed to handle 32-bit > transactions. However, it is now utilised for handling a variety of > object types, like TransactionId, MultixactId, MultiXactOffset, > QueuePosition, and so on. But the IO error reporting system is still > designed to support 32-bit XIDs exclusively. > > The proposed patchset allows us to define a "custom" callback to > improve error messages. > > The first two commits add a callback and test case. The subsequent ones > improve I/O error messages. The last one adds the XID epoch to the error > message. It's purely optional, but I think it would be useful. > > [0] https://www.postgresql.org/message-id/ > CACG%3Dezbwy1zargXDNPeYXxZwRW3jXu_aD%3DrcG-7dc4fw7Y9Ojw%40mail.gmail.com > CACG%3Dezbwy1zargXDNPeYXxZwRW3jXu_aD%3DrcG-7dc4fw7Y9Ojw%40mail.gmail.com> Thanks, looks reasonable. I'm -1 on the last patch, "Expand xact SLRU IO-error to show epoch" though. The epoch isn't used in addressing the SLRU, the patch just expands the 32-bit XID into a full 64-bit XID using the current epoch. That seems misleading. - Heikki