From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: pgsql: Don't trust unvalidated xl_tot_len. |
Date: | 2023-11-11 18:17:02 |
Message-ID: | CA+hUKGJrpmenQWXhTPQ4zqcqzT7e8gKFxrQLL3-9a+Wf1zrxtQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Sun, Nov 12, 2023 at 12:53 AM Christoph Berg <myon(at)debian(dot)org> wrote:
> Re: Thomas Munro
> > In the 13 branch we see that's in the new scan_server_header()
> > subroutine where it tries to open the header, after asking pg_config
> > --includedir-server where it lives. Hmm...
>
> It's no ok to use pg_config at test time since `make install` might
> not have been called yet:
>
> https://www.postgresql.org/message-id/2023925.1644591595@sss.pgh.pa.us
> https://www.postgresql.org/message-id/YqkV/hoi2SX91it8(at)paquier(dot)xyz
[CC'ing Michael who was involved in that analysis and who also wrote
those bits of this commit]
We don't have an installation into the final --prefix, but we have
tmp_install, surely? And the tests are run with PATH set to point to
tmp_install's bin directory. It looks like it did actually find a
pg_config executable because otherwise we'd have hit die "could not
execute pg_config" and failed sooner. So now I'm wondering if the
pg_config it found gives the wrong answer for --includedir-server,
because of Debian's local patches that insert a major version into
some paths. For example, maybe it's trying to look for
access/xlog_internal.h under tmp_install/usr/include/postgresql/server
when it's really under tmp_install/usr/include/postgresql/13/server,
or vice versa. But then why does that only happen on the salsa build,
not on the apt.postgresql.org one?
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2023-11-11 18:26:59 | Re: pgsql: Don't trust unvalidated xl_tot_len. |
Previous Message | Christoph Berg | 2023-11-11 11:53:37 | Re: pgsql: Don't trust unvalidated xl_tot_len. |
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2023-11-11 18:26:59 | Re: pgsql: Don't trust unvalidated xl_tot_len. |
Previous Message | Vladimir Churyukin | 2023-11-11 17:03:48 | Re: Making auto_explain more useful / convenient |