Re: pgsql: Don't trust unvalidated xl_tot_len.

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 23:17:54
Message-ID: CA+hUKG+=YFKc7LinctZyqQo6QYfxGEEcPefC9-osZxqEenAV2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sun, Nov 12, 2023 at 9:03 AM Christoph Berg <myon(at)debian(dot)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?

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Paquier 2023-11-12 00:22:20 Re: pgsql: Don't trust unvalidated xl_tot_len.
Previous Message Christoph Berg 2023-11-11 20:03:27 Re: pgsql: Don't trust unvalidated xl_tot_len.

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-11-12 00:22:20 Re: pgsql: Don't trust unvalidated xl_tot_len.
Previous Message Nathan Bossart 2023-11-11 21:49:43 Re: autovectorize page checksum code included elsewhere