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 1uvhw0-0007iC-Ty for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Sep 2025 19:53: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 1uvhvy-007Lor-VI for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Sep 2025 19:53: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.94.2) (envelope-from ) id 1uvhvy-007Loi-G1 for pgsql-hackers@lists.postgresql.org; Mon, 08 Sep 2025 19:53:50 +0000 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uvhvw-001DNQ-31 for pgsql-hackers@lists.postgresql.org; Mon, 08 Sep 2025 19:53:49 +0000 Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-b042cc39551so875430566b.0 for ; Mon, 08 Sep 2025 12:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757361227; x=1757966027; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Qf4KBIjcMCaDWeUif+WU4f206qNk6l5X0B4QetbP+6s=; b=jy2XhjUH3inaCv374dax/gOewODBS01EcJQSGZNmeRRy7F9dkKfc441r8pydUJyfaE PllGeLZmhkz/RS/xKZp7V8kCTTco0A6t72c8OlvsQ7h7cd2GtFM5Rre+Yot5joazihuY tzDQo5EB+WDNLR2mFn63FgijClJWKsFlYcciRLuc/ebw83hZ+VtKrgJl7m1lg3NfJ51H tw6UruGLvqpp69nYOmt+ee5S+PM5g6VT+QNq601B0cr76DEqiAbxULIULq8/TYnnLbfm usAD0L4yiktB36dEKtxpSXfDFlggyfYe5VT541/VIosjL//Np7giQTUA/XbnPrIm1oVQ fpnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757361227; x=1757966027; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Qf4KBIjcMCaDWeUif+WU4f206qNk6l5X0B4QetbP+6s=; b=bdsrurxuTrzP0bAiwvVO4kSoo9jK4mrVRtQM2TFM9IhnfOrYzKIxPa2HaqhgZzGgmr a62AYod1JNejPYAZGRJqtMOCD0cob6/M4yNO1Q7QLPguEj+1ZqMfgUtCFRwhb1Hin2bL i3lWCB/GV/qAdx0T+ua1DiUq+RHWUNoGoG15epGZnFJPcC13h3vxdKD0m8w6COpzKtOh rOMDJ2iVqXWg5ZbEDSh1uynvLG0ZZSrfpMUsfF50r3DFkz3GQ4KlBhZqskhUCrguGDt7 WKHlQQk7Ign88gCaUZVV8hTLlFhr63FwJfZMRJSyy6fJZLXiKRIAFg1LiUtfs82H+Y/9 LoLg== X-Forwarded-Encrypted: i=1; AJvYcCVtBCOFhktiGrdGru6tawiyKlWs2WdJAUj/RMEAJY2oZphs4KVsi9HyuUiAMhPYlcRZr6/GT248TjZNuOUc@lists.postgresql.org X-Gm-Message-State: AOJu0Yy51jWFEBow/9h9hjosEyOVW0MpHhxC67+ns4xr0KdnJDgdBA5s mandVafTovu/JusanqPW+/xyQHWyj9e3syE1ONTXX72TTCsfGzCXF3Et1ViZZbXilaYgVjYEZ4G SwDQrmCAVVKSamo4vxVAfo7zDk6VYqjQ= X-Gm-Gg: ASbGncuBHStzDU8/wBxZvc2vvmshYTkihRIIcaFJkfjaR0YJpwM4kegXouaO7vQEYp1 kltPlkshJnIzQrpVTxF77EXuR6EROYtKcBoga/InuL6JG/HaF9GvH5mVSYXTILOqTd9bTRy60dz tpDyCDuKS5ZXB9GIBWQ24wD8o0TA03o453YesA8ktNfTwkQ+Y4mTUoTOzMYv3dshJpLNo96773q Xm2kvby4gCWmnU453Y= X-Google-Smtp-Source: AGHT+IHiB/QFEe/gpsfx7+rvJcBRmtL2leASbQLQtoHTqMZhFzs0A7LZ31Sh+UoF/WC1URiN+Q6Sau7LxoOn+TSqlbo= X-Received: by 2002:a17:907:3f9d:b0:aff:16eb:8b09 with SMTP id a640c23a62f3a-b04b13cf9c8mr865605466b.5.1757361227147; Mon, 08 Sep 2025 12:53:47 -0700 (PDT) MIME-Version: 1.0 References: <87DD95AA-274F-4F4F-BAD9-7738E5B1F905@yandex-team.ru> In-Reply-To: From: Robert Haas Date: Mon, 8 Sep 2025 15:53:35 -0400 X-Gm-Features: Ac12FXy5SlWrI9gDa1EYbWNbQe30eu6VpaO6qiCXMtZfNo3suSSeWRW5VL-_Qyw Message-ID: Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) To: Melanie Plageman Cc: Andres Freund , Kirill Reshke , Andrey Borodin , PostgreSQL Hackers , Heikki Linnakangas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Sep 8, 2025 at 3:14=E2=80=AFPM Melanie Plageman wrote: > I noticed that in that thread they decided to use errmsg_internal() > instead of errmsg() for a few different reasons -- one of which was > that the situation is not supposed to happen/cannot happen -- which I > don't really understand. It is a reachable code path. Another is that > it is extra work for translators, which I'm also not sure how to apply > to my situation. Are the VM corruption cases worth extra work to the > translators? > > I think the most compelling reason is that people will want to search > for the error message in English online. So, for that reason, my > instinct is to use errmsg_internal() in my case as well. I don't find that reason particularly compelling -- people could want to search for any error message, or they could equally want to be able to read it without Google translate. Guessing which messages are obscure enough that we need not translate them exceeds my powers. If I were doing it, I'd make it errmsg() rather than errmsg_internal() and let the translations team change it if they don't think it's worth bothering with, because if you make it errmsg_internal() then they won't see it until somebody complains about it not getting translated. However, I suspect different committers would pursue different strategies here. --=20 Robert Haas EDB: http://www.enterprisedb.com