From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
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 20:03:27 |
Message-ID: | ZU_eD-JQCNA1tPSp@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
That's a lot of questions :). Let me try:
> In your chroot after it fails, can you please find xlog_internal.h
> somewhere under tmp_install and tell us the full path, and can you
./build/tmp_install/usr/include/postgresql/13/server/access/xlog_internal.h
./src/include/access/xlog_internal.h
> find pg_config (however many of them there might be, I'm a little
> confused on where and when Debian creates extra versioned variants)
That's only after testing and `make install`:
https://salsa.debian.org/postgresql/postgresql-common/-/blob/master/server/postgresql.mk#L219-225
> and tell us the full path,
./build/tmp_install/usr/lib/postgresql/13/bin/pg_config
./build/src/bin/pg_config/pg_config
> and also what --includedir-server prints,
$ ./build/tmp_install/usr/lib/postgresql/13/bin/pg_config --includedir-server
/usr/include/postgresql/13/server
> and can you also find regress_log_039_end_of_wal and confirm that it
> contains a complaint about being unable to open a file, not a
> complaint about being unable to execute pg_config?
$ cat ./build/src/test/recovery/tmp_check/log/regress_log_039_end_of_wal
No such file or directory at /home/myon/projects/postgresql/debian/13/build/../src/test/perl/TestLib.pm line 655.
The 13-bullseye version of the package still has the "don't relocate
me" patch:
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.
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.)
Christoph
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2023-11-11 23:17:54 | Re: pgsql: Don't trust unvalidated xl_tot_len. |
Previous Message | Andres Freund | 2023-11-11 19:43:25 | Re: pgsql: Don't trust unvalidated xl_tot_len. |
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2023-11-11 21:08:00 | Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan |
Previous Message | Andres Freund | 2023-11-11 19:43:25 | Re: pgsql: Don't trust unvalidated xl_tot_len. |