Re: pgsql: Don't trust unvalidated xl_tot_len. - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: pgsql: Don't trust unvalidated xl_tot_len.
Date
Msg-id CA+hUKG+=YFKc7LinctZyqQo6QYfxGEEcPefC9-osZxqEenAV2w@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Don't trust unvalidated xl_tot_len.  (Christoph Berg <myon@debian.org>)
Responses Re: pgsql: Don't trust unvalidated xl_tot_len.
List pgsql-hackers
On Sun, Nov 12, 2023 at 9:03 AM Christoph Berg <myon@debian.org> wrote:
> The PGBINDIR mangling is exactly what is breaking the use case now.
> The commit that removed that bit in the 15 branch explains why it was
> there:
>
> https://salsa.debian.org/postgresql/postgresql/-/commit/a249c75e86fe8733b11c47630e4931c5c196e8da
>
> I can (and should) do the change also in the other branches, but from
> the 2022 discussion, I had the impression there were more reasons to
> prefer static paths instead of calling pg_config from tmp_install.

No opinion on potential advantages to other approaches, but I don't
see why this way shouldn't be expected to work.  So I hope you can
drop that diff.

> After all, this seems to be the only 2nd case of actually calling
> pg_config from tests if I'm grepping for the right things - the other
> is check_pg_config() called from test/ssl/t/002_scram.pl. (I wonder
> why that's not failing as well.)

Maybe you aren't running the SSL tests?



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: autovectorize page checksum code included elsewhere
Next
From: Michael Paquier
Date:
Subject: Re: pgsql: Don't trust unvalidated xl_tot_len.