Re: pgsql: Don't trust unvalidated xl_tot_len.

On Sun, Nov 12, 2023 at 12:53 AM Christoph Berg <myon@debian.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@paquier.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?