be-secure-gssapi.c and auth.c with setenv() not compatible on Windows

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема be-secure-gssapi.c and auth.c with setenv() not compatible on Windows
Дата
Msg-id YLDtm5WGjPxm6ua4@paquier.xyz
обсуждение исходный текст
Ответы Re: be-secure-gssapi.c and auth.c with setenv() not compatible on Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi all,

Now that hamerkop has been fixed and that we have some coverage with
builds of GSSAPI on Windows thanks to 02511066, the buildfarm has been
complaining about a build failure on Windows for 12 and 13:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=hamerkop&dt=2021-05-28%2011%3A06%3A18&stg=make

The logs are hard to decrypt, but I guess that this is caused by the
use of setenv() in be-secure-gssapi.c and auth.c, as the tree has no
implementation that MSVC could feed on for those branches.

The recent commit 7ca37fb has changed things so as setenv() is used
instead of putenv(), and provides a fallback implementation, which
explains why the compilation of be-secure-gssapi.c and auth.c works
with MSVC, as reported by hamerkop.

We can do two things here:
1) Switch be-secure-gssapi.c and auth.c to use putenv().
2) Backport into 12 and 13 the fallback implementation of setenv
introduced in 7ca37fb, and keep be-secure-gssapi.c as they are now.

It is worth noting that 860fe27 mentions the use of setenv() in
be-secure-gssapi.c but has done nothing for it.  I would choose 1), on
the ground that adding a new file on back-branches adds an additional
cost to Windows maintainers if they use their own MSVC scripts (I know
of one case here that would be impacted), and that does not seem
mandatory here as putenv() would just work.

Thoughts?
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Decoding speculative insert with toast leaks memory
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Decoding speculative insert with toast leaks memory