Re: Let's start using setenv() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Let's start using setenv()
Date
Msg-id 2197258.1609277151@sss.pgh.pa.us
Whole thread Raw
In response to Re: Let's start using setenv()  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Dec 30, 2020 at 5:45 AM Tom Lane <tgl@sss.pgh.pa.us> 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Weird failure in explain.out with OpenBSD
Next
From: David Rowley
Date:
Subject: Re: Cleanup some -I$(libpq_srcdir) in makefiles