Re: Let's start using setenv()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Let's start using setenv()
Date: 2020-12-29 21:25:51
Message-ID: 2197258.1609277151@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Wed, Dec 30, 2020 at 5:45 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-12-29 21:54:45 Re: Cleanup some -I$(libpq_srcdir) in makefiles
Previous Message Tom Lane 2020-12-29 21:16:06 Re: Weird failure in explain.out with OpenBSD