Re: pgsql: Don't trust unvalidated xl_tot_len.
| От | Thomas Munro |
|---|---|
| Тема | Re: pgsql: Don't trust unvalidated xl_tot_len. |
| Дата | |
| Msg-id | CA+hUKG+=YFKc7LinctZyqQo6QYfxGEEcPefC9-osZxqEenAV2w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pgsql: Don't trust unvalidated xl_tot_len. (Christoph Berg <myon@debian.org>) |
| Ответы |
Re: pgsql: Don't trust unvalidated xl_tot_len.
|
| Список | 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 по дате отправления: