On Sun, Nov 12, 2023 at 12:17:54PM +1300, Thomas Munro wrote:
> 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.
Another thing that could be done in stable branches is just to switch
039_end_o
On Sun, Nov 12, 2023 at 9:03 AM Christoph Berg 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/a249c75e86fe8733b11c47630e4931c5c
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
> f
Hi,
On 2023-11-12 07:17:02 +1300, Thomas Munro wrote:
> On Sun, Nov 12, 2023 at 12:53 AM Christoph Berg 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-se
On Sun, Nov 12, 2023 at 7:27 AM Christoph Berg wrote:
> I can confirm that it's also failing in my local chroots if none of
> the postgresql-* packages are preinstalled.
In your chroot after it fails, can you please find xlog_internal.h
somewhere under tmp_install and tell us the full path, and c
Re: Thomas Munro
> But then why does that only happen on the salsa build,
> not on the apt.postgresql.org one?
The build chroots there have postgresql-NN already installed so
extension builds don't have to download 7 PG versions over and over.
My guess would be that that's the difference and it's
On Sun, Nov 12, 2023 at 12:53 AM Christoph Berg 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 t
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:
http
On Sat, Nov 11, 2023 at 10:42 AM Christoph Berg wrote:
> > I haven't investigated the details yet, and it's not affecting the
> > builds on apt.postgresql.org, but the Debian amd64 and i386 regression
> > tests just failed this test on PG13 (11 and 15 are ok):
>
> 12 and 14 are also failing, now o
Re: To Thomas Munro
> > src/test/recovery/t/039_end_of_wal.pl | 460
> >
>
> I haven't investigated the details yet, and it's not affecting the
> builds on apt.postgresql.org, but the Debian amd64 and i386 regression
> tests just failed this test on PG13 (11 and
Re: To Thomas Munro
> I haven't investigated the details yet, and it's not affecting the
> builds on apt.postgresql.org, but the Debian amd64 and i386 regression
> tests just failed this test on PG13 (11 and 15 are ok):
That's on Debian bullseye, fwiw. (But the 13 build on apt.pg.o/bullseye passed
Re: Thomas Munro
> Don't trust unvalidated xl_tot_len.
> src/test/recovery/t/039_end_of_wal.pl | 460
I haven't investigated the details yet, and it's not affecting the
builds on apt.postgresql.org, but the Debian amd64 and i386 regression
tests just failed this
12 matches
Mail list logo
