Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kuMVC-0005qg-Ry for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Dec 2020 21:25:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kuMVA-0007nx-R2 for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Dec 2020 21:25:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kuMVA-0007nq-K8 for pgsql-hackers@lists.postgresql.org; Tue, 29 Dec 2020 21:25:56 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kuMV8-0001Li-1a for pgsql-hackers@lists.postgresql.org; Tue, 29 Dec 2020 21:25:55 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 0BTLPp7B2197259; Tue, 29 Dec 2020 16:25:51 -0500 From: Tom Lane To: Thomas Munro cc: PostgreSQL Hackers Subject: Re: Let's start using setenv() In-reply-to: References: <2065122.1609212051@sss.pgh.pa.us> <2079685.1609219313@sss.pgh.pa.us> <2152500.1609260303@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Wed, 30 Dec 2020 09:34:59 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2197257.1609277151.1@sss.pgh.pa.us> Date: Tue, 29 Dec 2020 16:25:51 -0500 Message-ID: <2197258.1609277151@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thomas Munro writes: > On Wed, Dec 30, 2020 at 5:45 AM Tom Lane wrote: > + /* We assume the error must be "out of memory" */ > + ereport(LOG, > + (errcode(ERRCODE_OUT_OF_MEMORY), > + errmsg("out of memory"))); > Wouldn't it be better to do "cannot set environment: %m" or similar, > and let ENOMEM do its thing if that be the cause? That's no problem as far as the error text goes, but we lack a way to choose a relevant errcode(). I guess I could fix it for ENOMEM specifically, along the lines of errcode(errno == ENOMEM ? ERRCODE_OUT_OF_MEMORY : ERRCODE_INTERNAL_ERROR) This is a bit trickier than it looks though, because code within an ereport macro isn't really supposed to rely on errno still being the same as at entry. Is it worth inventing an errcode_for_errno() helper routine, which could look at the stashed errno? Or maybe extending/abusing errcode_for_file_access() so it recognizes ENOMEM? Or we could just use ERRCODE_OUT_OF_MEMORY, without being too picky about whether that's accurate. > Did you want to drop the canonicalize_path() logic here and nearby? Yeah, because the results of get_locale_path et al are already canonicalized, so those canonicalize_path calls are redundant. Thanks for looking at the patch! regards, tom lane