Re: Let's start using setenv()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Let's start using setenv()
Дата
Msg-id 2197258.1609277151@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Let's start using setenv()  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Weird failure in explain.out with OpenBSD
Следующее
От: David Rowley
Дата:
Сообщение: Re: Cleanup some -I$(libpq_srcdir) in makefiles