Re: fix: propagate M4 env variable to flex subprocess - Mailing list pgsql-hackers

From J. Javier Maestro
Subject Re: fix: propagate M4 env variable to flex subprocess
Date
Msg-id CABvji06MWroeU8N56i5_MxzEhLKTpncQBP+N9FiWtNWK3N1W3w@mail.gmail.com
Whole thread Raw
In response to Re: fix: propagate M4 env variable to flex subprocess  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, May 20, 2025 at 8:53 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
Hi,

On Tue, 13 May 2025 at 18:54, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2025-05-12 23:14:59 -0400, J. Javier Maestro wrote:
> > The pgflex wrapper runs flex with an explicit environment, so it doesn't
> > inherit environment variables from the parent process. However, flex can
> > use the M4 env variable and/or the PATH (via execvp) to find the m4 macro
> > processor.
>
> > Thus, since flex honors the M4 env variable, it should be propagated to the
> > subprocess environment if it's set in the parent environment. This patch
> > fixes it.
>
> I think it probably was not intentional to fully specify the environment,
> rather than just *adding* FLEX_TMP_DIR to the caller's environment. Bilal, I
> think you wrote this originally, do you recall?

I found the original pull request [1] but it does not include the
'FLEX_TMP_DIR' part. I tried to search where the 'FLEX_TMP_DIR' part
is added [2], it seems that this part is added while rebasing so there
is no specific commit.

[1] https://github.com/anarazel/postgres/pull/51
[2] https://github.com/anarazel/postgres/commit/cd817afd4ab006b90307a940d96b5116d649165c

Thanks for the context.

Apart from these pointers to the original PRs, could you (and Andres) give me feedback on the patch? Do you think it's OK to merge? Should I add it to a commitfest?

On this note, on top of that patch, I also have other patches that I think would be relevant. Given that you and Andres seem to use Github, here are the patches that I would like to discuss:



The last one is more of a "hack" but still, it shows the issues with the current approach to "embedding metadata" in header files that end up in the binaries.

What would be the most effective way to discuss these patches? Would it be better to go one-by-one or to create a new thread focused on discussing reproducibility, to discuss all of them?

Thanks a lot beforehand for your help,

Regards,

Javier

pgsql-hackers by date:

Previous
From: Dimitrios Apostolou
Date:
Subject: [PING] fallocate() causes btrfs to never compress postgresql files
Next
From: Tom Lane
Date:
Subject: Re: wrong query results on bf leafhopper