Re: kerberos/001_auth test fails on arm CPU darwin
On 09/26/2022 8:25 pm, Michael Paquier wrote: On Mon, Sep 26, 2022 at 04:39:36PM +0200, Peter Eisentraut wrote: On 26.09.22 13:14, Tom Lane wrote: Bilal Yavuz writes: > It seems that kerberos is installed at the '/opt/homebrew/opt/krb5' path on > ARM CPU darwin instances instead of the '/usr/local/opt/krb5' path. I think this also needs to account for MacPorts, which would likely put it under /opt/local/sbin. (I wonder where /usr/local/opt/krb5 came from at all -- that sounds like somebody's manual installation rather than a packaged one.) /usr/local/opt/ is used by Homebrew on Intel macOS. Hmm. Is that the case with new setups under x86_64? I have a M1 where everything goes through /opt/homebrew/, though it has been set very recently. -- Michael Intel: wf-corporate-chef on master +6 -420 [✘!] on ☁️ (us-east-1) on ﴃ WhereTo - Prod ❯ /usr/local/opt/krb5/bin/krb5-config --prefix /usr/local/Cellar/krb5/1.20 wf-corporate-chef on master +6 -420 [✘!] on ☁️ (us-east-1) on ﴃ WhereTo - Prod ❯ Same on my M1 iMac (migrated from an Intel iMac however) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: kerberos/001_auth test fails on arm CPU darwin
On 09/26/2022 11:39 am, Nazir Bilal Yavuz wrote: Hi, On 9/26/2022 2:14 PM, Tom Lane wrote: Maybe we should first try "krb5-config --prefix" to see if that gives an answer. I tested that command on multiple OSes and it was correct for freeBSD, debian and openSUSE. I don't have macOS so I tried to use CI for running macOS VMs(both arm and Intel CPU): When "krb5-config" binary is used from brew or MacPorts installations' path it gives the correct path but there is another "krb5-config" binary at "/usr/bin/krb5-config" path on the macOS VMs, when this binary is used while running "krb5-config --prefix" command run it gives "/" as output. This issue can be related about the CI VMs but I couldn't check it. Regards, Nazir Bilal Yavuz on macOS monterey 12.6: ~ via v3.1.2 on ☁️ (us-east-1) on ﴃ WhereTo - Prod ❯ krb5-config --prefix / ~ via v3.1.2 on ☁️ (us-east-1) on ﴃ WhereTo - Prod ❯ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Ubuntu 16.04: Xenial: Why was it removed from the apt repo?
All of a sudden I'm getting repo not found for Ubuntu 16.04 LTS on the APT repo. Why? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: head fails to build on SLES 12
On 03/31/2022 2:58 pm, Andrew Dunstan wrote: On 3/31/22 10:23, Devrim Gündüz wrote: Hi, Latest snapshot tarball fails to build on SLES 12.5, which uses GCC 4.8-8. Build log is attached. Please let me know if you want me to provide more info. AFAICT we don't have any buildfarm animals currently reporting on SLES 12 (and the one we did have was on s390x, if that matters). So if this is something that needs support we should address that. After all, that's exactly what the buildfarm was created for. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com I can spin up a VM on SLES 12 assuming someone can point me to the right place to get an ISO, etc, and I don't need a payfor license. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Buildfarm support for older versions
l Studio 8\Common7\Tools',
'C:\Program Files\Microsoft Visual Studio
8\Common7\Tools\bin',
'C:\Program Files\Microsoft Visual Studio
8\VC\PlatformSDK\bin',
'C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin',
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727',
'C:\Program Files\Microsoft Visual Studio 8\VC\VCPackages',
'C:\Perl\Bin',
'c:\prog\pgdepend\bin',
$ENV{PATH}),
INCLUDE => join(';',
'C:\Program Files\Microsoft Visual Studio
8\VC\ATLMFC\INCLUDE',
'C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE',
'C:\Program Files\Microsoft Visual Studio
8\VC\PlatformSDK\include',
'C:\Program Files\Microsoft Visual Studio
8\SDK\v2.0\include',
$ENV{INCLUDE}),
LIB => join(';',
'C:\Program Files\Microsoft Visual Studio 8\VC\ATLMFC\LIB',
'C:\Program Files\Microsoft Visual Studio 8\VC\LIB'
.'C:\Program Files\Microsoft Visual Studio
8\VC\PlatformSDK\lib',
'C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\lib'
.$ENV{LIB}),
LIBPATH => join(';',
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727',
'C:\Program Files\Microsoft Visual Studio 8\VC\ATLMFC\LIB'),
);
%{$conf{build_env}} = (%{$conf{build_env}}, %extra_buildenv);
# MSVC needs a somewhat different style of config opts (why??)
# What we write here will be literally (via Data::Dumper) put into
# the config.pl file for the MSVC build.
$conf{config_opts} ={
asserts=>1, # --enable-cassert
integer_datetimes=>1, # --enable-integer-datetimes
nls=>undef, # --enable-nls=
tcl=>'c:\tcl', # --with-tcl=
perl=>'c:\perl',# --with-perl=
python=>'c:\python25', # --with-python=
krb5=> undef, # --with-krb5=
ldap=>0,# --with-ldap
openssl=> undef,# --with-ssl=
xml=> undef,# --with-libxml=
xslt=> undef, # --with-libxslt=,
iconv=> undef, # path to iconv library
zlib=> undef, # --with-zlib=
};
}
##
#
# examples of per branch processing
# tailor as required for your site.
#
##
if ($branch eq 'HEAD')
{
# push(@{$conf{config_opts}},"--enable-depend");
}
elsif ($branch =~ /^REL7_/)
{
#push(@{$conf{config_opts}},"--without-tk");
}
1;
$
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Thu Dec 23 18:33:48 2021: buildfarm run for gerenuk:REL9_2_STABLE starting
gerenuk:REL9_2_STABLE [18:33:48] checking out source ...
gerenuk:REL9_2_STABLE [18:33:51] checking if build run needed ...
gerenuk:REL9_2_STABLE [18:33:51] copying source to pgsql.build ...
gerenuk:REL9_2_STABLE [18:33:53] running configure ...
gerenuk:REL9_2_STABLE [18:34:19] running make ...
gerenuk:REL9_2_STABLE [18:36:02] running make check ...
gerenuk:REL9_2_STABLE [18:36:29] running make contrib ...
gerenuk:REL9_2_STABLE [18:36:39] running make install ...
gerenuk:REL9_2_STABLE [18:36:45] running make contrib install ...
gerenuk:REL9_2_STABLE [18:36:48] checking pg_upgrade
gerenuk:REL9_2_STABLE [18:37:57] running make check miscellaneous modules ...
gerenuk:REL9_2_STABLE [18:37:57] setting up db cluster (C)...
gerenuk:REL9_2_STABLE [18:38:00] starting db (C)...
gerenuk:REL9_2_STABLE [18:38:01] running make installcheck (C)...
gerenuk:REL9_2_STABLE [18:38:27] restarting db (C)...
gerenuk:REL9_2_STABLE [18:38:30] running make isolation check ...
gerenuk:REL9_2_STABLE [18:38:46] restarting db (C)...
gerenuk:REL9_2_STABLE [18:38:49] running make PL installcheck (C)...
gerenuk:REL9_2_STABLE [18:38:51] restarting db (C)...
gerenuk:REL9_2_STABLE [18:38:54] running make contrib installcheck (C)...
gerenuk:REL9_2_STABLE [18:39:11] stopping db (C)...
gerenuk:REL9_2_STABLE [18:39:13] running make ecpg check ...
gerenuk:REL9_2_STABLE [18:39:46] OK
Branch: REL9_2_STABLE
All stages succeeded
Thu Dec 23 18:39:47 2021: buildfarm run for gerenuk:REL9_3_STABLE starting
gerenuk:REL9_3_STABLE [18:39:47] checking out source ...
gerenuk:REL9_3_STABLE [18:39:52] checking if build run needed ...
gerenuk:REL9_3_STABLE [18:39:52] copying source to pgsql.build ...
gerenuk:REL9_3_STABLE [18:39:54] running configure ...
gerenuk:REL9_3_STABLE [18:40:23] running make ...
gerenuk:REL9_3_STABLE [18:42:06] running make check ...
gerenuk:REL9_3_STABLE [18:42:31] running make contrib ...
gerenuk:REL9_3_STABLE [18:42:42] running make install ...
gerenuk:REL9_
Re: Buildfarm support for older versions
On 12/23/2021 11:23 am, Andrew Dunstan wrote:
On 12/23/21 11:27, Larry Rosenman wrote:
For the 9.2 error, try setting this in the config_env stanza:
CFLAGS => '-O2 -fPIC',
That got us further, but it dies on startdb:
$ cat startdb-C-1.log
waiting for server to start stopped waiting
pg_ctl: could not start server
Examine the log output.
=== db log file ==
LOG: unrecognized configuration parameter "unix_socket_directories"
in file
"/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/data-C/postgresql.conf"
line 576
FATAL: configuration file
"/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/data-C/postgresql.conf"
contains errors
$
And we have the errors on the other branches with a temp(?) directory.
looks like it's picking up the wrong perl libraries. Please show us the
output of
grep -v secret
/home/pgbuildfarm/buildroot/REL9_2_STABLE/$animal.lastrun-logs/web-txn.data
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
$ grep -v secret web-txn.data
$changed_this_run = '';
$changed_since_success = '';
$branch = 'REL9_2_STABLE';
$status = 1;
$stage = 'StartDb-C:1';
$animal = 'gerenuk';
$ts = 1640276469;
$log_data = 'Last file mtime in snapshot: Wed Dec 15 23:00:28 2021 GMT
===
waiting for server to start stopped waiting
pg_ctl: could not start server
Examine the log output.
=== db log file ==
LOG: unrecognized configuration parameter "unix_socket_directories" in
file
"/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/data-C/postgresql.conf"
line 576
FATAL: configuration file
"/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/data-C/postgresql.conf"
contains errors
';
$confsum = 'This file was created by PostgreSQL configure 9.2.24, which
was
generated by GNU Autoconf 2.63. Invocation command line was
$ ./configure --enable-cassert --enable-debug --enable-nls
--enable-tap-tests \\
--with-perl
--prefix=/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst \\
--with-pgport=5700
--cache-file=/home/pgbuildfarm/buildroot/accache-gerenuk/config-REL9_2_STABLE.cache
hostname = borg.lerctr.org
uname -m = amd64
uname -r = 14.0-CURRENT
uname -s = FreeBSD
uname -v = FreeBSD 14.0-CURRENT #26 main-n251898-acdc1de369a: Wed Dec 22
18:11:08 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
/usr/bin/uname -p = amd64
PATH: /home/ler/.asdf/shims
PATH: /home/ler/.asdf/bin
PATH: /sbin
PATH: /bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /home/ler/bin
PATH: /home/ler/go/bin
PATH: /usr/local/opt/terraform@0.12/bin
PATH: /home/ler/bin
$Script_Config = {
\'alerts\' => {},
\'animal\' => \'gerenuk\',
\'base_port\' => 5678,
\'bf_perl_version\' => \'5.32.1\',
\'build_env\' => {
\'INCLUDES\' =>
\'-I/usr/local/include\',
\'LDFLAGS\' => \'-L/usr/local/lib\'
},
\'build_root\' => \'/home/pgbuildfarm/buildroot\',
\'ccache_failure_remove\' => undef,
\'config\' => [],
\'config_env\' => {
\'CFLAGS\' => \'-O2 -fPIC\'
},
\'config_opts\' => [
\'--enable-cassert\',
\'--enable-debug\',
\'--enable-nls\',
\'--enable-tap-tests\',
\'--with-perl\'
],
\'core_file_glob\' => \'*.core*\',
\'extra_config\' => {
\'DEFAULT\' => [
\'log_line_prefix
= \\\'%m [%p:%l] %q%a \\\'\',
\'log_connections
= \\\'true\\\'\',
\'log_disconnections = \\\'true\\\'\',
\'log_statement =
\\\'all\\\'\',
\'fsync = off\'
]
},
\'force_every\' => {},
\'git_ignore_mirror_failure\' => 1,
\'git_keep_mirror\' => 1,
\'git_use_workdirs\' => 1,
\'invocation_args\' => [
\'--config\',
Re: Buildfarm support for older versions
On 12/23/2021 10:13 am, Andrew Dunstan wrote: On 12/23/21 08:50, Andrew Dunstan wrote: On 12/22/21 23:20, Larry Rosenman wrote: On 12/22/2021 10:15 pm, Tom Lane wrote: Larry Rosenman writes: On 12/22/2021 9:59 pm, Tom Lane wrote: Does it work if you drop --enable-nls? (It'd likely be worth fixing if so, but I'm trying to narrow the possible causes.) Nope... OK. Since 9.3 succeeds, it seems like it's a link problem we fixed at some point. Can you bisect to find where we fixed it? regards, tom lane I can try -- I haven't been very good at that. I can give you access to the machine and the id the Buildfarm runs under. (or give me a good process starting from a buildfarm layout). I will work on it on my FBSD setup. For the 9.2 error, try setting this in the config_env stanza: CFLAGS => '-O2 -fPIC', cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com That got us further, but it dies on startdb: $ cat startdb-C-1.log waiting for server to start stopped waiting pg_ctl: could not start server Examine the log output. === db log file == LOG: unrecognized configuration parameter "unix_socket_directories" in file "/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/data-C/postgresql.conf" line 576 FATAL: configuration file "/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/data-C/postgresql.conf" contains errors $ And we have the errors on the other branches with a temp(?) directory. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Buildfarm support for older versions
On 12/22/2021 10:15 pm, Tom Lane wrote: Larry Rosenman writes: On 12/22/2021 9:59 pm, Tom Lane wrote: Does it work if you drop --enable-nls? (It'd likely be worth fixing if so, but I'm trying to narrow the possible causes.) Nope... OK. Since 9.3 succeeds, it seems like it's a link problem we fixed at some point. Can you bisect to find where we fixed it? regards, tom lane I can try -- I haven't been very good at that. I can give you access to the machine and the id the Buildfarm runs under. (or give me a good process starting from a buildfarm layout). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Buildfarm support for older versions
On 12/22/2021 9:59 pm, Tom Lane wrote: Larry Rosenman writes: On 12/22/2021 9:34 pm, Tom Lane wrote: What configure options did you use? config_opts =>[ qw( --enable-cassert --enable-debug --enable-nls --enable-tap-tests --with-perl ) ], Does it work if you drop --enable-nls? (It'd likely be worth fixing if so, but I'm trying to narrow the possible causes.) regards, tom lane Nope... gmake[3]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/contrib/dummy_seclabel' cp ../../../contrib/dummy_seclabel/dummy_seclabel.so dummy_seclabel.so cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-sometimes-uninitialized -g -fPIC -DPIC -L../../src/port -L/usr/local/lib -Wl,--as-needed -Wl,-R'/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/lib' -L../../src/port -lpgport -shared -o moddatetime.so moddatetime.o cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-sometimes-uninitialized -g -fPIC -DPIC -L../../src/port -L/usr/local/lib -Wl,--as-needed -Wl,-R'/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/lib' -L../../src/port -lpgport -shared -o insert_username.so insert_username.o cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-sometimes-uninitialized -g -fPIC -DPIC -L../../src/port -L/usr/local/lib -Wl,--as-needed -Wl,-R'/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/lib' -L../../src/port -lpgport -shared -o autoinc.so autoinc.o cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-sometimes-uninitialized -g -fPIC -DPIC -L../../src/port -L/usr/local/lib -Wl,--as-needed -Wl,-R'/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/lib' -L../../src/port -lpgport -shared -o timetravel.so timetravel.o cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-sometimes-uninitialized -g -fPIC -DPIC -L../../src/port -L/usr/local/lib -Wl,--as-needed -Wl,-R'/home/pgbuildfarm/buildroot/REL9_2_STABLE/inst/lib' -L../../src/port -lpgport -shared -o refint.so refint.o ld: error: relocation R_X86_64_PC32 cannot be used against symbol _CurrentRuneLocale; recompile with -fPIC defined in /lib/libc.so.7 referenced by pgstrcasecmp.c:37 pgstrcasecmp.o:(pg_strcasecmp) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol __mb_sb_limit; recompile with -fPIC defined in /lib/libc.so.7 referenced by pgstrcasecmp.c:37 pgstrcasecmp.o:(pg_strcasecmp) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol _CurrentRuneLocale; recompile with -fPIC defined in /lib/libc.so.7 referenced by pgstrcasecmp.c:70 pgstrcasecmp.o:(pg_strncasecmp) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol __mb_sb_limit; recompile with -fPIC defined in /lib/libc.so.7 referenced by pgstrcasecmp.c:70 pgstrcasecmp.o:(pg_strncasecmp) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol __mb_sb_limit; recompile with -fPIC defined in /lib/libc.so.7 referenced by pgstrcasecmp.c:109 pgstrcasecmp.o:(pg_toupper) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol _CurrentRuneLocale; recompile with -fPIC defined in /lib/libc.so.7 referenced by runetype.h:0 (/usr/include/runetype.h:0) pgstrcasecmp.o:(pg_toupper) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol __mb_sb_limit; recompile with -fPIC defined in /lib/libc.so.7 referenced by pgstrcasecmp.c:126 pgstrcasecmp.o:(pg_tolower) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol _CurrentRuneLocale; recompile with -fPIC defined in /lib/libc.so.7 referenced by runetype.h:0 (/usr/include/runetype.h:0) pgstrcasecm
Re: Buildfarm support for older versions
On 12/22/2021 9:34 pm, Tom Lane wrote: Larry Rosenman writes: REL9_2_STABLE make dies on: ld: error: relocation R_X86_64_PC32 cannot be used against symbol _CurrentRuneLocale; recompile with -fPIC [etc] What configure options did you use? regards, tom lane config_opts =>[ qw( --enable-cassert --enable-debug --enable-nls --enable-tap-tests --with-perl ) ], -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Buildfarm support for older versions
On 12/22/2021 7:16 pm, Larry Rosenman wrote: On 12/22/2021 7:20 am, Andrew Dunstan wrote: On 12/21/21 15:06, Larry Rosenman wrote: I filled out that form on the 16th, and haven't gotten a new animal assignment. Is there a problem with my data? It's a manual process, done when your friendly admins have time. I have approved it now. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com REL9_2_STABLE make dies on: gmake[4]: Entering directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/src/backend/utils' '/usr/bin/perl' ./generate-errcodes.pl ../../../src/backend/utils/errcodes.txt > errcodes.h cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-sometimes-uninitialized -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o path.o path.c gmake[4]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/src/backend/utils' prereqdir=`cd 'utils/' >/dev/null && pwd` && \ cd '../../src/include/utils/' && rm -f errcodes.h && \ ln -s "$prereqdir/errcodes.h" . gmake[3]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/src/backend' cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing $ tail -30 make.log ld: error: relocation R_X86_64_PC32 cannot be used against symbol __mb_sb_limit; recompile with -fPIC defined in /lib/libc.so.7 referenced by pgstrcasecmp.c:109 pgstrcasecmp.o:(pg_toupper) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol _CurrentRuneLocale; recompile with -fPIC defined in /lib/libc.so.7 referenced by runetype.h:0 (/usr/include/runetype.h:0) pgstrcasecmp.o:(pg_toupper) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol __mb_sb_limit; recompile with -fPIC defined in /lib/libc.so.7 referenced by pgstrcasecmp.c:126 pgstrcasecmp.o:(pg_tolower) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol _CurrentRuneLocale; recompile with -fPIC defined in /lib/libc.so.7 referenced by runetype.h:0 (/usr/include/runetype.h:0) pgstrcasecmp.o:(pg_tolower) in archive ../../src/port/libpgport.a cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[3]: *** [../../src/Makefile.port:20: timetravel.so] Error 1 gmake[3]: *** Waiting for unfinished jobs rm moddatetime.o autoinc.o refint.o timetravel.o insert_username.o gmake[3]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/contrib/spi' gmake[2]: *** [GNUmakefile:126: submake-contrib-spi] Error 2 gmake[2]: *** Waiting for unfinished jobs gmake[2]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/src/test/regress' gmake[1]: *** [Makefile:33: all-test/regress-recurse] Error 2 gmake[1]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/src' gmake: *** [GNUmakefile:11: all-src-recurse] Error 2 $ The other branches are still running. Here's the full run: $ bin/latest/run_branches.pl --test --config $(pwd)/conf/gerenuk.conf --run-all Wed Dec 22 19:05:53 2021: buildfarm run for gerenuk:REL9_2_STABLE starting gerenuk:REL9_2_STABLE [19:05:54] checking out source ... gerenuk:REL9_2_STABLE [19:06:06] checking if build run needed ... gerenuk:REL9_2_STABLE [19:06:06] copying source to pgsql.build ... gerenuk:REL9_2_STABLE [19:06:08] running configure ... gerenuk:REL9_2_STABLE [19:06:36] running make ... Branch: REL9_2_STABLE Stage Make failed with status 2 Wed Dec 22 19:08:21 2021: buildfarm run for gerenuk:REL9_3_STABLE starting gerenuk:REL9_3_STABLE [19:08:21] checking out source ... gerenuk:REL9_3_STABLE [19:08:27] checking if build run needed ... gerenuk:REL9_3_STABLE [19:08:28] copying source to pgsql.build ... gerenuk:REL9_3_STABLE [19:08:29] running configure ... gerenuk:REL9_3_STABLE [19:08:52] running make ... gerenuk:REL9_3_STABLE [19:10:38] running make check ... gerenuk:REL9_3_STABLE [19:11:05] running make contrib ... gerenuk:REL9_3_STABLE [19:11:15] running make install ... gerenuk:REL9_3_STABLE [19:11:19] running make contrib install ... gerenuk:REL9_3_STABLE [19:11:21] checking pg_upgrade gerenuk:REL9_3_STABLE [19:12:29] running make check miscellaneous modules ... gerenuk:REL9_3_STABLE [19:12:29] setting up db cluster (C)... gerenuk:REL9_3_STABLE [19:12:32] starting db (C)... gerenuk:REL9_3_STABLE [19:12:33] running make installcheck (C)... gerenuk:REL9_3_STABLE [19:13:00] restarting db (C)... gerenuk:REL9_3_STABLE [19:13:03] running make isolation check ... g
Re: Buildfarm support for older versions
On 12/22/2021 7:20 am, Andrew Dunstan wrote: On 12/21/21 15:06, Larry Rosenman wrote: I filled out that form on the 16th, and haven't gotten a new animal assignment. Is there a problem with my data? It's a manual process, done when your friendly admins have time. I have approved it now. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com REL9_2_STABLE make dies on: gmake[4]: Entering directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/src/backend/utils' '/usr/bin/perl' ./generate-errcodes.pl ../../../src/backend/utils/errcodes.txt > errcodes.h cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-sometimes-uninitialized -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o path.o path.c gmake[4]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/src/backend/utils' prereqdir=`cd 'utils/' >/dev/null && pwd` && \ cd '../../src/include/utils/' && rm -f errcodes.h && \ ln -s "$prereqdir/errcodes.h" . gmake[3]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/src/backend' cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing $ tail -30 make.log ld: error: relocation R_X86_64_PC32 cannot be used against symbol __mb_sb_limit; recompile with -fPIC defined in /lib/libc.so.7 referenced by pgstrcasecmp.c:109 pgstrcasecmp.o:(pg_toupper) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol _CurrentRuneLocale; recompile with -fPIC defined in /lib/libc.so.7 referenced by runetype.h:0 (/usr/include/runetype.h:0) pgstrcasecmp.o:(pg_toupper) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol __mb_sb_limit; recompile with -fPIC defined in /lib/libc.so.7 referenced by pgstrcasecmp.c:126 pgstrcasecmp.o:(pg_tolower) in archive ../../src/port/libpgport.a ld: error: relocation R_X86_64_PC32 cannot be used against symbol _CurrentRuneLocale; recompile with -fPIC defined in /lib/libc.so.7 referenced by runetype.h:0 (/usr/include/runetype.h:0) pgstrcasecmp.o:(pg_tolower) in archive ../../src/port/libpgport.a cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[3]: *** [../../src/Makefile.port:20: timetravel.so] Error 1 gmake[3]: *** Waiting for unfinished jobs rm moddatetime.o autoinc.o refint.o timetravel.o insert_username.o gmake[3]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/contrib/spi' gmake[2]: *** [GNUmakefile:126: submake-contrib-spi] Error 2 gmake[2]: *** Waiting for unfinished jobs gmake[2]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/src/test/regress' gmake[1]: *** [Makefile:33: all-test/regress-recurse] Error 2 gmake[1]: Leaving directory '/home/pgbuildfarm/buildroot/REL9_2_STABLE/pgsql.build/src' gmake: *** [GNUmakefile:11: all-src-recurse] Error 2 $ The other branches are still running. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Buildfarm support for older versions
On 12/16/2021 3:23 pm, Andrew Dunstan wrote: On 12/16/21 15:53, Larry Rosenman wrote: I get: ERROR for site owner: Invalid domain for site key on https://pgbuildfarm.org/cgi-bin/register-form.pl try https://buildfarm.postgresql.org/cgi-bin/register-form.pl cheers andrew I filled out that form on the 16th, and haven't gotten a new animal assignment. Is there a problem with my data? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Buildfarm support for older versions
On 12/16/2021 2:47 pm, Andrew Dunstan wrote: On 12/16/21 12:26, Larry Rosenman wrote: On 12/16/2021 11:17 am, Andrew Dunstan wrote: On 12/16/21 11:11, Larry Rosenman wrote: A new animal, because we're not supporting every build option. On the non-live branches you really only want: --enable-debug --enable-cassert --enable-nls --enable-tap-tests --with-perl You can make it share the same storage as your existing animal (godwit and crake do this). The client is smart enough to manage locks of several animals appropriately. So just create a new animal / config file, and set those options? and FreeBSD head / main would be useful? (Currently FreeBSD 14 and clang 13). Sure. I think if we get coverage for modern Linux, FreeBSD and Windows we should be in good shape. I doubt we need a heck of a lot of animals - there's not going to be much going on here. Would you mind terribly giving me the exact steps? * register a new animal with the same details * copy your existing config file to $new_animal.conf * edit the file and change the animal name and secret, the config_opts as above, and remove TestUpgrade form the modules setting * change branches_to_build to [qw( REL9_2_STABLE REL9_3_STABLE REL9_4_STABLE REL9_5_STABLE REL9_6_STABLE)] * you should probably unset CCACHEDIR in both config files * test with ./run_branches --test --config $newanimal.conf --run-all I get: ERROR for site owner: Invalid domain for site key on https://pgbuildfarm.org/cgi-bin/register-form.pl -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Buildfarm support for older versions
On 12/16/2021 11:17 am, Andrew Dunstan wrote: On 12/16/21 11:11, Larry Rosenman wrote: A new animal, because we're not supporting every build option. On the non-live branches you really only want: --enable-debug --enable-cassert --enable-nls --enable-tap-tests --with-perl You can make it share the same storage as your existing animal (godwit and crake do this). The client is smart enough to manage locks of several animals appropriately. So just create a new animal / config file, and set those options? and FreeBSD head / main would be useful? (Currently FreeBSD 14 and clang 13). Sure. I think if we get coverage for modern Linux, FreeBSD and Windows we should be in good shape. I doubt we need a heck of a lot of animals - there's not going to be much going on here. cheers andrew Would you mind terribly giving me the exact steps? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Buildfarm support for older versions
On 12/16/2021 10:02 am, Andrew Dunstan wrote: On 12/15/21 21:36, Larry Rosenman wrote: On 12/15/2021 11:15 am, Andrew Dunstan wrote: OK, old_branches_of_interest.txt now exists on the buildfarm server, and the code has been modified to take notice of it (i.e. to accept builds for branches listed there). The contents are the non-live versions from 9.2 on. I have set up a test buildfarm client (which will eventually report under the name 'godwit') alongside crake (Fedora 34). So far testing has run smoothly, there are only two glitches: * 9.3 and 9.2 don't have a show_dl_suffix make target. This would require backpatching b40cb99b85 and d9cdb1ba9e. That's a tiny change, and I propose to do it shortly unless there's an objection. * I need to undo the removal of client logic that supported 9.2's unix_socket_directory setting as opposed to the later unix_socket_directories. Would a FreeBSD head (peripatus or a new animal) help? A new animal, because we're not supporting every build option. On the non-live branches you really only want: --enable-debug --enable-cassert --enable-nls --enable-tap-tests --with-perl You can make it share the same storage as your existing animal (godwit and crake do this). The client is smart enough to manage locks of several animals appropriately. cheers andrew -- So just create a new animal / config file, and set those options? and FreeBSD head / main would be useful? (Currently FreeBSD 14 and clang 13). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Buildfarm support for older versions
On 12/15/2021 11:15 am, Andrew Dunstan wrote: OK, old_branches_of_interest.txt now exists on the buildfarm server, and the code has been modified to take notice of it (i.e. to accept builds for branches listed there). The contents are the non-live versions from 9.2 on. I have set up a test buildfarm client (which will eventually report under the name 'godwit') alongside crake (Fedora 34). So far testing has run smoothly, there are only two glitches: * 9.3 and 9.2 don't have a show_dl_suffix make target. This would require backpatching b40cb99b85 and d9cdb1ba9e. That's a tiny change, and I propose to do it shortly unless there's an objection. * I need to undo the removal of client logic that supported 9.2's unix_socket_directory setting as opposed to the later unix_socket_directories. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com Would a FreeBSD head (peripatus or a new animal) help? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: is possible an remote access to some macos?
On 10/11/2021 8:49 pm, Noah Misch wrote: On Mon, Oct 11, 2021 at 06:31:03AM +0200, Pavel Stehule wrote: I would like to fix an issue https://github.com/okbob/pspg/issues/188 where the write to clipboard from pspg doesn`t work on macos. But it is hard to fix it without any macos. I am not a user of macos and I would not buy it just for this purpose. Is it possible to get some remote ssh access? You can request a GCC Compile Farm account (https://cfarm.tetaneutral.net/users/new/). AWS also has macos instances: https://aws.amazon.com/pm/ec2-mac/ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Peripatus: Can someone look?
On 10/01/2019 8:33 pm, Thomas Munro wrote:
On Wed, Oct 2, 2019 at 4:49 AM Larry Rosenman wrote:
On 10/01/2019 10:46 am, Tom Lane wrote:
> Larry Rosenman writes:
>> My Buildfarm animal (peripatus) has been failing check since
>> yesterday.
>> Can someone look at it?
>
> It's been doing this in parallel queries, in v11 and up:
>
> 2019-09-29 19:00:15.534 CDT [49513:1] ERROR: could not open shared
> memory segment "/PostgreSQL.1225945786": Permission denied
> 2019-09-29 19:00:15.535 CDT [48596:491] pg_regress/partition_prune
> ERROR: parallel worker failed to initialize
> 2019-09-29 19:00:15.535 CDT [48596:492] pg_regress/partition_prune
> HINT: More details may be available in the server log.
> 2019-09-29 19:00:15.535 CDT [48596:493] pg_regress/partition_prune
> CONTEXT: PL/pgSQL function explain_parallel_append(text) line 5 at
> FOR over EXECUTE statement
> 2019-09-29 19:00:15.535 CDT [48596:494] pg_regress/partition_prune
> STATEMENT: select explain_parallel_append('select avg(ab.a) from ab
> inner join lprt_a a on ab.a = a.a where a.a in(1, 0, 0)');
> 2019-09-29 19:00:15.535 CDT [48596:495] pg_regress/partition_prune
> WARNING: could not remove shared memory segment
> "/PostgreSQL.1225945786": Permission denied
>
> which looks like an external problem to me --- certainly, nothing
> we changed yesterday would explain it. Did you change anything
> about the system configuration, or do a software update?
>
> regards, tom lane
I did do an upgrade to a later SVN rev.
Let me reboot and see if that fixes anything.
(this is -CURRENT on FreeBSD, so it's always a moving target).
Hi Larry,
I'm seeing this on my FreeBSD 13 bleeding edge system too (built a
couple of days ago) and will see if I can find out what's up with
that. The most obvious culprit is the stuff that just landed in the
kernel to support Linux-style memfd_create() and thereby changed
around some shm_open() related things. Seems to be clearly not a
PostgreSQL problem.
Thanks,
Thomas
Thanks, Thomas.
Here's my 2 SVN revs if that would help:
FreeBSD SVN rev:
r352600 - - 1.69G 2019-09-22 13:13
r352873 NR / 43.1G 2019-09-29 16:36
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: My buildfarm member now giving permission denied
On 10/01/2019 8:27 pm, Larry Rosenman wrote: FreeBSD SVN rev: r352600 - - 1.69G 2019-09-22 13:13 r352873 NR / 43.1G 2019-09-29 16:36 I went from r352600 to r352873 and now I'm getting PostgreSQL permission denied errors on the check phase of the build. FreeBSD folks: Any ideas? PostgreSQL folks: FYI. latest build log: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2019-10-02%2001%3A20%3A14 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
My buildfarm member now giving permission denied
FreeBSD SVN rev: r352600 - - 1.69G 2019-09-22 13:13 r352873 NR / 43.1G 2019-09-29 16:36 I went from r352600 to r352873 and now I'm getting PostgreSQL permission denied errors on the check phase of the build. FreeBSD folks: Any ideas? PostgreSQL folks: FYI. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Peripatus: Can someone look?
On 10/01/2019 10:46 am, Tom Lane wrote:
Larry Rosenman writes:
My Buildfarm animal (peripatus) has been failing check since
yesterday.
Can someone look at it?
It's been doing this in parallel queries, in v11 and up:
2019-09-29 19:00:15.534 CDT [49513:1] ERROR: could not open shared
memory segment "/PostgreSQL.1225945786": Permission denied
2019-09-29 19:00:15.535 CDT [48596:491] pg_regress/partition_prune
ERROR: parallel worker failed to initialize
2019-09-29 19:00:15.535 CDT [48596:492] pg_regress/partition_prune
HINT: More details may be available in the server log.
2019-09-29 19:00:15.535 CDT [48596:493] pg_regress/partition_prune
CONTEXT: PL/pgSQL function explain_parallel_append(text) line 5 at
FOR over EXECUTE statement
2019-09-29 19:00:15.535 CDT [48596:494] pg_regress/partition_prune
STATEMENT: select explain_parallel_append('select avg(ab.a) from ab
inner join lprt_a a on ab.a = a.a where a.a in(1, 0, 0)');
2019-09-29 19:00:15.535 CDT [48596:495] pg_regress/partition_prune
WARNING: could not remove shared memory segment
"/PostgreSQL.1225945786": Permission denied
which looks like an external problem to me --- certainly, nothing
we changed yesterday would explain it. Did you change anything
about the system configuration, or do a software update?
regards, tom lane
I did do an upgrade to a later SVN rev.
Let me reboot and see if that fixes anything.
(this is -CURRENT on FreeBSD, so it's always a moving target).
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Peripatus: Can someone look?
My Buildfarm animal (peripatus) has been failing check since yesterday. Can someone look at it? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: How am I supposed to fix this?
On 08/06/2019 1:16 pm, Peter Geoghegan wrote: On Tue, Aug 6, 2019 at 11:11 AM Larry Rosenman wrote: As a followup, btcheck found another index that had issues, and a toast table was missing a chunk. I have ALL the data I used to create this table still around so I just dropped it and am reloading the data. It sounds like there is a generic storage issue at play here. Often TOAST data is the apparent first thing that gets corrupted, because that's only because the inconsistencies are relatively obvious. I suggest that you rerun amcheck using the same query, though this time specify "heapallindexed=true" to bt_check_index(). Increase maintenance_work_mem if it's set to a low value first (ideally you can crank it up to 600MB). This type of verification will take a lot longer, but will find more subtle inconsistencies that could easily be missed. Please let us know how this goes. I am always keen to hear about how much the tooling helps in the real world. I've already dropped and re-created the table involved (a metric crapton of DNS queries). I know why and how this happened as well. I had to fully restore my system, and bacula didn't catch all the data etc since it was being modified, and I didn't do the smart thing then and restore from a pg_dump. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: How am I supposed to fix this?
On 08/06/2019 12:45 pm, Larry Rosenman wrote: On 08/06/2019 12:35 pm, Peter Geoghegan wrote: On Tue, Aug 6, 2019 at 10:34 AM Larry Rosenman wrote: ERROR: function bt_index_check(index => oid) does not exist LINE 1: SELECT bt_index_check(index => c.oid), ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. It's a contrib extension, so you have to "create extension amcheck" first. the check is running (this is a HUGE table). For the initial error, it would be nice if: 1) the pg_toast schema was mentioned or 2) reindex searched pg_toast as well. I did do the reindex pg_toast. index. As a followup, btcheck found another index that had issues, and a toast table was missing a chunk. I have ALL the data I used to create this table still around so I just dropped it and am reloading the data. I still think that the error message should mention the fully qualified index name. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: How am I supposed to fix this?
On 08/06/2019 12:35 pm, Peter Geoghegan wrote: On Tue, Aug 6, 2019 at 10:34 AM Larry Rosenman wrote: ERROR: function bt_index_check(index => oid) does not exist LINE 1: SELECT bt_index_check(index => c.oid), ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. It's a contrib extension, so you have to "create extension amcheck" first. the check is running (this is a HUGE table). For the initial error, it would be nice if: 1) the pg_toast schema was mentioned or 2) reindex searched pg_toast as well. I did do the reindex pg_toast. index. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: How am I supposed to fix this?
On 08/06/2019 12:30 pm, Peter Geoghegan wrote: On Tue, Aug 6, 2019 at 10:19 AM Tomas Vondra wrote: The question is how much other data corruption is there ... Larry could try running amcheck on the other indexes. Just the basic bt_check_index() checks should be enough to detect problems like this. They can be run fairly non-disruptively. Something like this should do it: SELECT bt_index_check(index => c.oid), c.relname, c.relpages FROM pg_index i JOIN pg_opclass op ON i.indclass[0] = op.oid JOIN pg_am am ON op.opcmethod = am.oid JOIN pg_class c ON i.indexrelid = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid WHERE am.amname = 'btree' -- Don't check temp tables, which may be from another session: AND c.relpersistence != 't' -- Function may throw an error when this is omitted: AND c.relkind = 'i' AND i.indisready AND i.indisvalid ORDER BY c.relpages DESC; If this takes too long, you can always adjust the query to only verify system indexes or TOAST indexes. ler=# SELECT bt_index_check(index => c.oid), ler-#c.relname, ler-#c.relpages ler-# FROM pg_index i ler-# JOIN pg_opclass op ON i.indclass[0] = op.oid ler-# JOIN pg_am am ON op.opcmethod = am.oid ler-# JOIN pg_class c ON i.indexrelid = c.oid ler-# JOIN pg_namespace n ON c.relnamespace = n.oid ler-# WHERE am.amname = 'btree' ler-# -- Don't check temp tables, which may be from another session: ler-# AND c.relpersistence != 't' ler-# -- Function may throw an error when this is omitted: ler-# AND c.relkind = 'i' AND i.indisready AND i.indisvalid ler-# ORDER BY c.relpages DESC; ERROR: function bt_index_check(index => oid) does not exist LINE 1: SELECT bt_index_check(index => c.oid), ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. ler=# -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
How am I supposed to fix this?
I'm getting the below, and am unaware of how to fix it 11.4 on FreeBSD 12. ler=# reindex (verbose) table dns_query ; INFO: index "dns_query_pkey" was reindexed DETAIL: CPU: user: 114.29 s, system: 207.94 s, elapsed: 698.87 s ERROR: index "pg_toast_17760_index" contains unexpected zero page at block 23686 HINT: Please REINDEX it. CONTEXT: parallel worker ler=# reindex index pg_toast_17760_index; ERROR: relation "pg_toast_17760_index" does not exist ler=# reindex (verbose) database ler; INFO: index "pg_class_oid_index" was reindexed DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s INFO: index "pg_class_relname_nsp_index" was reindexed DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s INFO: index "pg_class_tblspc_relfilenode_index" was reindexed DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s INFO: table "pg_catalog.pg_class" was reindexed load: 14.53 cmd: psql 2675 [select] 2765.27r 0.01u 0.01s 0% 8292k INFO: index "dns_query_pkey" was reindexed DETAIL: CPU: user: 112.91 s, system: 205.51 s, elapsed: 688.28 s ERROR: index "pg_toast_17760_index" contains unexpected zero page at block 23686 HINT: Please REINDEX it. ler=# ler=# select version(); version - PostgreSQL 11.4 on amd64-portbld-freebsd12.0, compiled by FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0), 64-bit (1 row) ler=# -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: New committer: David Rowley
On 05/30/2019 10:39 am, Magnus Hagander wrote: > Hi! > > For those of you that have not read the minutes from the developer meeting > ahead of pgcon (can be found at > https://wiki.postgresql.org/wiki/PgCon_2019_Developer_Meeting), we'd like to > announce here as well that David Rowley has joined the ranks of PostgreSQL > committers. > > Congratulations to David, may the buildfarm be gentle to him, and his first > revert far away! Congrats! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: DSM robustness failure (was Re: Peripatus/failures)
On Wed, Oct 17, 2018 at 08:19:52PM -0500, Larry Rosenman wrote: > On Thu, Oct 18, 2018 at 02:17:14PM +1300, Thomas Munro wrote: > > On Thu, Oct 18, 2018 at 1:10 PM Tom Lane wrote: > > > ... However, I'm still slightly interested in how it > > > was that that broke DSM so thoroughly ... > > > > Me too. Frustratingly, that vm object might still exist on Larry's > > machine if it hasn't been rebooted (since we failed to shm_unlink() > > it), so if we knew its name we could write a program to shm_open(), > > mmap(), dump out to a file for analysis and then we could work out > > which of the sanity tests it failed and maybe get some clues. > > Unfortunately it's not in any of our logs AFAIK, and I can't see any > > way to get a list of existing shm_open() objects from the kernel. > > From sys/kern/uipc_shm.c: > > > > * TODO: > > * > > * (1) Need to export data to a userland tool via a sysctl. Should ipcs(1) > > * and ipcrm(1) be expanded or should new tools to manage both POSIX > > * kernel semaphores and POSIX shared memory be written? > > > > Gah. So basically that's hiding in shm_dictionary in the kernel and I > > don't know a way to look at it from userspace (other than trying to > > open all 2^32 random paths we're capable of generating). > > It has *NOT* been rebooted. I can give y'all id's if you want to go > poking around. Let me know soon(ish) if any of you want to poke at this machine, as I'm likely to forget and reboot it. > > > > > > -- > > Thomas Munro > > http://www.enterprisedb.com > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org > US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: DSM robustness failure (was Re: Peripatus/failures)
On Thu, Oct 18, 2018 at 02:17:14PM +1300, Thomas Munro wrote: > On Thu, Oct 18, 2018 at 1:10 PM Tom Lane wrote: > > ... However, I'm still slightly interested in how it > > was that that broke DSM so thoroughly ... > > Me too. Frustratingly, that vm object might still exist on Larry's > machine if it hasn't been rebooted (since we failed to shm_unlink() > it), so if we knew its name we could write a program to shm_open(), > mmap(), dump out to a file for analysis and then we could work out > which of the sanity tests it failed and maybe get some clues. > Unfortunately it's not in any of our logs AFAIK, and I can't see any > way to get a list of existing shm_open() objects from the kernel. > From sys/kern/uipc_shm.c: > > * TODO: > * > * (1) Need to export data to a userland tool via a sysctl. Should ipcs(1) > * and ipcrm(1) be expanded or should new tools to manage both POSIX > * kernel semaphores and POSIX shared memory be written? > > Gah. So basically that's hiding in shm_dictionary in the kernel and I > don't know a way to look at it from userspace (other than trying to > open all 2^32 random paths we're capable of generating). It has *NOT* been rebooted. I can give y'all id's if you want to go poking around. > > -- > Thomas Munro > http://www.enterprisedb.com -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: DSM robustness failure (was Re: Peripatus/failures)
On Wed, Oct 17, 2018 at 08:55:09PM -0400, Tom Lane wrote: > Larry Rosenman writes: > > On Wed, Oct 17, 2018 at 08:10:28PM -0400, Tom Lane wrote: > >> However, I'm still slightly interested in how it > >> was that that broke DSM so thoroughly ... I pulled down your version of > >> python2.7 and will see if that reproduces it. > > > It was built on a previous alpha, so who knows what the differing > > compiler/libs/kernel/etc did. The options used did *NOT* change, just > > the userland used to compile it. (I.E. that package, running on > > ALPHA10 is what broke). > > Hm. I forcibly installed your package over the regular one using > pkg add -f python27-2.7.15.txz > and rebuilt PG, and what I get is a failure in the plpython regression > test, but no crash. So I'm still confused. Hell if I know. I've cleaned up my environment (old, broken, etc stuff), but who knows whats broken what where. Not sure how to get back to the "broken" state :( -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: DSM robustness failure (was Re: Peripatus/failures)
On Wed, Oct 17, 2018 at 08:10:28PM -0400, Tom Lane wrote: > Larry Rosenman writes: > > On Wed, Oct 17, 2018 at 07:07:09PM -0400, Tom Lane wrote: > >> ... Was your Python install built > >> with any special switches? I just used what came from "pkg install". > > > It had been built on a previous FreeBSD build, I have my own poudriere > > infrastructure. I can probably get you the package from my ZFS snaps if > > you'd like. > > I've now verified that the bog-standard packages for python 2.7 and python > 3.6 both build and pass regression cleanly, using ALPHA10. And I see > peripatus is back to green too. So as far as the plpython end of this is > concerned, I think we can write it off as "something wrong with Larry's > custom package build". However, I'm still slightly interested in how it > was that that broke DSM so thoroughly ... I pulled down your version of > python2.7 and will see if that reproduces it. > It was built on a previous alpha, so who knows what the differing compiler/libs/kernel/etc did. The options used did *NOT* change, just the userland used to compile it. (I.E. that package, running on ALPHA10 is what broke). that's one of the nice things about poudriere, it's a clean room type environment, and uses canned options as set by the user, and I haven't changed python options in a LONG (I.E. months/years) time. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: DSM robustness failure (was Re: Peripatus/failures)
On Wed, Oct 17, 2018 at 07:07:09PM -0400, Tom Lane wrote: > Larry Rosenman writes: > > On the original failure, I recompiled and reinstalled the 2 Python's I > > have on this box, and at least 9.3 went back to OK. > > Hmm. I'd just finished pulling down FreeBSD-12.0-ALPHA9 and failing > to reproduce any problem with that ... and then I noticed your box > said it was on ALPHA10, which I'd missed seeing in the clutter of > FreeBSD's download server. I'm about halfway through switching to > that, but I bet it will work too. Was your Python install built > with any special switches? I just used what came from "pkg install". It had been built on a previous FreeBSD build, I have my own poudriere infrastructure. I can probably get you the package from my ZFS snaps if you'd like. > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: DSM robustness failure (was Re: Peripatus/failures)
On Thu, Oct 18, 2018 at 11:08:33AM +1300, Thomas Munro wrote: > On Thu, Oct 18, 2018 at 9:43 AM Thomas Munro > wrote: > > On Thu, Oct 18, 2018 at 9:00 AM Tom Lane wrote: > > > I would argue that both dsm_postmaster_shutdown and dsm_postmaster_startup > > > are broken here; the former because it makes no attempt to unmap > > > the old control segment (which it oughta be able to do no matter how badly > > > broken the contents are), and the latter because it should not let > > > garbage old state prevent it from establishing a valid new segment. > > > > Looking. > > (CCing Amit Kapila) > > To reproduce this, I attached lldb to a backend and did "mem write > _control->magic 42", and then delivered SIGKILL to the backend. > Here's one way to fix it. I think we have no choice but to leak the > referenced segments, but we can free the control segment. See > comments in the attached patch for rationale. > On the original failure, I recompiled and reinstalled the 2 Python's I have on this box, and at least 9.3 went back to OK. > -- > Thomas Munro > http://www.enterprisedb.com -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: Peripatus/failures
On Wed, Oct 17, 2018 at 01:41:59PM -0400, Tom Lane wrote: > Larry Rosenman writes: > > It looks like my upgrade to the current head of FreeBSD 12-to-be, which > > includes OpenSSL 1.1.1 broke a bunch of our stuff. > > In at least the 9.x branches. Just a heads up. > > It looks like configure is drawing the wrong conclusions about OpenSSL's > API options. Since the configure outputs are cached, perhaps clearing > your buildfarm critter's accache subdirectory would be enough to fix that. > That got it further, but still fails at PLCheck-C (at least on 9.3). It's still running the other branches. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
Peripatus/failures
It looks like my upgrade to the current head of FreeBSD 12-to-be, which includes OpenSSL 1.1.1 broke a bunch of our stuff. In at least the 9.x branches. Just a heads up. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
Re: Odd 9.4, 9.3 buildfarm failure on s390x
On Mon, Oct 01, 2018 at 05:11:02PM -0400, Tom Lane wrote: > Andrew Dunstan writes: > > On 10/01/2018 11:58 AM, Tom Lane wrote: > >> Oooh ... apparently, on that platform, memcmp() is willing to produce > >> INT_MIN in some cases. That's not a safe value for a sort comparator > >> to produce --- we explicitly say that somewhere, IIRC. I think we > >> implement DESC by negating the comparator's result, which explains > >> why only the DESC case fails. > > > Is there a standard that forbids this, or have we just been lucky up to now? > > We've been lucky; POSIX just says the value is less than, equal to, > or greater than zero. > > In practice, a memcmp that operates byte-at-a-time would not likely > return anything outside +-255. But on a big-endian machine you could > easily optimize to use word-wide operations to compare 4 bytes at a > time, and I suspect that's what's happening here. Or maybe there's > just some weird architecture-specific reason that makes it cheap > for them to return INT_MIN rather than some other value? > as a former S3[79]x assembler programmer, they probably do it in registers or using TRT. All of which could be word wise. > regards, tom lane > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: peripatus build failures....
It was never put into the build, and I have a PR open to remove the LLD_UNSAFE flag for 10.5 and the rest of today's releases. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229523 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 On 8/9/18, 3:25 PM, "Alvaro Herrera" wrote: On 2018-Jul-09, Larry Rosenman wrote: > On Mon, Jul 09, 2018 at 05:25:50PM -0400, Tom Lane wrote: > > I wrote: > > > I'd been hesitant to back-patch dddfc4cb2 back in April; but now that > > > it's survived some beta testing, I think that doing so seems like the > > > most appropriate way to fix this. > > > > Done. Hopefully I didn't break anything; a lot of this code has mutated > > to some extent since 9.3. But I expect the buildfarm will point out any > > problems. > > The reason you might not have seen it on FreeBSD before is that FreeBSD > 12 now uses lld (llvm's LD) to link, and it changed the default for -z. So, has the hack for -z notext been removed from the freebsd port build? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: peripatus build failures....
On Mon, Jul 09, 2018 at 05:25:50PM -0400, Tom Lane wrote: > I wrote: > > I'd been hesitant to back-patch dddfc4cb2 back in April; but now that > > it's survived some beta testing, I think that doing so seems like the > > most appropriate way to fix this. > > Done. Hopefully I didn't break anything; a lot of this code has mutated > to some extent since 9.3. But I expect the buildfarm will point out any > problems. The reason you might not have seen it on FreeBSD before is that FreeBSD 12 now uses lld (llvm's LD) to link, and it changed the default for -z. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: peripatus build failures....
On Sat, Jul 07, 2018 at 01:33:26PM -0500, Larry Rosenman wrote: > On Sat, Jul 07, 2018 at 02:28:17PM -0400, Tom Lane wrote: > > Larry Rosenman writes: > > > And the winner is: > > > > > dddfc4cb2edcfa5497f5d50190a7fb046c51da16 is the first bad commit > > > commit dddfc4cb2edcfa5497f5d50190a7fb046c51da16 > > > Author: Tom Lane > > > Date: Tue Apr 3 16:26:05 2018 -0400 > > > > > > Prevent accidental linking of system-supplied copies of libpq.so etc. > > > > Huh. So what that suggests is that the problem is related to picking > > up copies of our libraries from outside the build tree. Do you have > > any copies of libpgport.a/.so or libpgcommon.a/.so in > > /usr/local/lib or /usr/lib or /lib ? > > > > regards, tom lane > > Yes > borg.lerctr.org /home/ler $ ls /usr/local/lib/libpg* > /usr/local/lib/libpgcommon.a /usr/local/lib/libpgport.a > /usr/local/lib/libpgtypes.a /usr/local/lib/libpgtypes.so > /usr/local/lib/libpgtypes.so.3 > borg.lerctr.org /home/ler $ ls -l /usr/local/lib/libpg* > -rw-r--r-- 1 root wheel 190410 Jun 29 12:11 /usr/local/lib/libpgcommon.a > -rw-r--r-- 1 root wheel 80234 May 11 19:08 /usr/local/lib/libpgport.a > -rw-r--r-- 1 root wheel 112312 May 11 19:08 /usr/local/lib/libpgtypes.a > lrwxr-xr-x 1 root wheel 15 May 11 19:08 /usr/local/lib/libpgtypes.so > -> libpgtypes.so.3 > -rwxr-xr-x 1 root wheel 77726 May 11 19:08 /usr/local/lib/libpgtypes.so.3 > borg.lerctr.org /home/ler $ > And: borg.lerctr.org /home/ler $ pkg which -g /usr/local/lib/libpgport.a /usr/local/lib/libpgport.a was installed by package postgresql10-client-10.4 borg.lerctr.org /home/ler $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
Re: peripatus build failures....
On Sat, Jul 07, 2018 at 02:28:17PM -0400, Tom Lane wrote: > Larry Rosenman writes: > > And the winner is: > > > dddfc4cb2edcfa5497f5d50190a7fb046c51da16 is the first bad commit > > commit dddfc4cb2edcfa5497f5d50190a7fb046c51da16 > > Author: Tom Lane > > Date: Tue Apr 3 16:26:05 2018 -0400 > > > > Prevent accidental linking of system-supplied copies of libpq.so etc. > > Huh. So what that suggests is that the problem is related to picking > up copies of our libraries from outside the build tree. Do you have > any copies of libpgport.a/.so or libpgcommon.a/.so in > /usr/local/lib or /usr/lib or /lib ? > > regards, tom lane Yes borg.lerctr.org /home/ler $ ls /usr/local/lib/libpg* /usr/local/lib/libpgcommon.a/usr/local/lib/libpgport.a /usr/local/lib/libpgtypes.a /usr/local/lib/libpgtypes.so /usr/local/lib/libpgtypes.so.3 borg.lerctr.org /home/ler $ ls -l /usr/local/lib/libpg* -rw-r--r-- 1 root wheel 190410 Jun 29 12:11 /usr/local/lib/libpgcommon.a -rw-r--r-- 1 root wheel 80234 May 11 19:08 /usr/local/lib/libpgport.a -rw-r--r-- 1 root wheel 112312 May 11 19:08 /usr/local/lib/libpgtypes.a lrwxr-xr-x 1 root wheel 15 May 11 19:08 /usr/local/lib/libpgtypes.so -> libpgtypes.so.3 -rwxr-xr-x 1 root wheel 77726 May 11 19:08 /usr/local/lib/libpgtypes.so.3 borg.lerctr.org /home/ler $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: peripatus build failures....
On Sat, Jul 07, 2018 at 11:24:48AM -0400, Tom Lane wrote: > Larry Rosenman writes: > > On Sat, Jul 07, 2018 at 11:11:24AM -0400, Tom Lane wrote: > >> Larry Rosenman writes: > >>> f044d71e331d77a0039cec0a11859b5a3c72bc95 fixed it. > > >> Don't think I believe that conclusion; that patch shouldn't > >> have affected anything at all for non-ARM architectures. > > > Those are the 2 adjacent commits in src/port. > > You're assuming something not in evidence, which is that the critical > change was textually within src/port/. It might have been in configure, > for instance, or in Makefile.global, or some other upper-level makefile. > I'd just do a straight bisect run without any assumptions about which part > of the tree matters. > > regards, tom lane And the winner is: dddfc4cb2edcfa5497f5d50190a7fb046c51da16 is the first bad commit commit dddfc4cb2edcfa5497f5d50190a7fb046c51da16 Author: Tom Lane Date: Tue Apr 3 16:26:05 2018 -0400 Prevent accidental linking of system-supplied copies of libpq.so etc. We were being careless in some places about the order of -L switches in link command lines, such that -L switches referring to external directories could come before those referring to directories within the build tree. This made it possible to accidentally link a system-supplied library, for example /usr/lib/libpq.so, in place of the one built in the build tree. Hilarity ensued, the more so the older the system-supplied library is. To fix, break LDFLAGS into two parts, a sub-variable LDFLAGS_INTERNAL and the main LDFLAGS variable, both of which are "recursively expanded" so that they can be incrementally adjusted by different makefiles. Establish a policy that -L switches for directories in the build tree must always be added to LDFLAGS_INTERNAL, while -L switches for external directories must always be added to LDFLAGS. This is sufficient to ensure a safe search order. For simplicity, we typically also put -l switches for the respective libraries into those same variables. (Traditional make usage would have us put -l switches into LIBS, but cleaning that up is a project for another day, as there's no clear need for it.) This turns out to also require separating SHLIB_LINK into two variables, SHLIB_LINK and SHLIB_LINK_INTERNAL, with a similar rule about which switches go into which variable. And likewise for PG_LIBS. Although this change might appear to affect external users of pgxs.mk, I think it doesn't; they shouldn't have any need to touch the _INTERNAL variables. In passing, tweak src/common/Makefile so that the value of CPPFLAGS recorded in pg_config lacks "-DFRONTEND" and the recorded value of LDFLAGS lacks "-L../../../src/common". Both of those things are mistakes, apparently introduced during prior code rearrangements, as old versions of pg_config don't print them. In general we don't want anything that's specific to the src/common subdirectory to appear in those outputs. This is certainly a bug fix, but in view of the lack of field complaints, I'm unsure whether it's worth the risk of back-patching. In any case it seems wise to see what the buildfarm makes of it first. Discussion: https://postgr.es/m/25214.1522604...@sss.pgh.pa.us :04 04 49374c1617930b2ff57015188d2f06ff15198fb0 c07d24d934ac3f8e8a60e533953b1ea1a1411824 M contrib :04 04 d00cbb0746730fabc32828a839033fbe6bb1aba8 51f1c15d4802aaae90e527eeca38611b73802f47 M src borg.lerctr.org /home/ler/Git/postgresql $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: peripatus build failures....
On Sat, Jul 07, 2018 at 11:11:24AM -0400, Tom Lane wrote: > Larry Rosenman writes: > > f044d71e331d77a0039cec0a11859b5a3c72bc95 fixed it. > > Don't think I believe that conclusion; that patch shouldn't > have affected anything at all for non-ARM architectures. > > regards, tom lane Those are the 2 adjacent commits in src/port. gitlog, and the 2 gmake outputs at: https://www.lerctr.org/~ler/PostgreSQL/ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: peripatus build failures....
On Fri, Jul 06, 2018 at 07:18:46PM -0400, Tom Lane wrote: > Larry Rosenman writes: > > On Fri, Jul 06, 2018 at 06:40:49PM -0400, Tom Lane wrote: > >> I do not like the "-Wl,-z,notext" thing at all. It fails to explain > >> why things are working OK in v11/HEAD, which makes me think that it's > >> band-aiding something rather than really fixing it. > > > Following the advice in the error message, the following ALSO fixes it > > (REL_10_STABLE): > > +override CFLAGS := -fPIC > > Yeah, I wondered about whether that wasn't a cleaner answer, but the same > problem remains: if we need that in src/port/, why don't all the branches > need it? It would be unsurprising if we'd gained a requirement for -fPIC > somewhere along the line, but I don't entirely believe that we lost one. > So I'd still like to know when this changed. > BROKE:0c62356cc8777961221a643fa77f62e1c7361085 GOOD: f044d71e331d77a0039cec0a11859b5a3c72bc95 f044d71e331d77a0039cec0a11859b5a3c72bc95 fixed it. Here's the revs I tried: BROKE:9d4649ca49416111aee2c84b7e4441a0b7aa2fac GOOD: 3b8f6e75f3c8c6d192621f21624cc8cee04ec3cb GOOD: 3a5e0a91bb324ad2b2b1a0623a3f2e37772b43fc GOOD: 8989f52b1b0636969545e6c8f6c813bc563ebcf5 BROKE:0c62356cc8777961221a643fa77f62e1c7361085 GOOD: f044d71e331d77a0039cec0a11859b5a3c72bc95 > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: peripatus build failures....
On Fri, Jul 06, 2018 at 06:05:36PM -0500, Larry Rosenman wrote: > On Fri, Jul 06, 2018 at 06:40:49PM -0400, Tom Lane wrote: > > Larry Rosenman writes: > > > anyone want to look at this, or at least give me a clue on how to add > > > this to 10 & below? > > > > I do not like the "-Wl,-z,notext" thing at all. It fails to explain > > why things are working OK in v11/HEAD, which makes me think that it's > > band-aiding something rather than really fixing it. > > > > Perhaps you could spend a bit of time with git bisect and find out > > which commit un-broke things? That should help us narrow down the > > true explanation. > > > > regards, tom lane > > Following the advice in the error message, the following ALSO fixes it > (REL_10_STABLE): > > borg.lerctr.org /home/ler/Git/postgresql/src/port $ git diff > diff --git a/src/port/Makefile b/src/port/Makefile > index 81f01b25bb..9ef00b3d54 100644 > --- a/src/port/Makefile > +++ b/src/port/Makefile > @@ -28,6 +28,7 @@ top_builddir = ../.. > include $(top_builddir)/src/Makefile.global > > override CPPFLAGS := -I$(top_builddir)/src/port -DFRONTEND $(CPPFLAGS) > +override CFLAGS := -fPIC > LIBS += $(PTHREAD_LIBS) > > OBJS = $(LIBOBJS) $(PG_CRC32C_OBJS) chklocale.o erand48.o inet_net_ntop.o \ > borg.lerctr.org /home/ler/Git/postgresql/src/port $ > > Is that more acceptable? Err, add a $(CFLAGS) to the end of the added line. > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org > US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: peripatus build failures....
On Fri, Jul 06, 2018 at 06:40:49PM -0400, Tom Lane wrote: > Larry Rosenman writes: > > anyone want to look at this, or at least give me a clue on how to add > > this to 10 & below? > > I do not like the "-Wl,-z,notext" thing at all. It fails to explain > why things are working OK in v11/HEAD, which makes me think that it's > band-aiding something rather than really fixing it. > > Perhaps you could spend a bit of time with git bisect and find out > which commit un-broke things? That should help us narrow down the > true explanation. > > regards, tom lane Following the advice in the error message, the following ALSO fixes it (REL_10_STABLE): borg.lerctr.org /home/ler/Git/postgresql/src/port $ git diff diff --git a/src/port/Makefile b/src/port/Makefile index 81f01b25bb..9ef00b3d54 100644 --- a/src/port/Makefile +++ b/src/port/Makefile @@ -28,6 +28,7 @@ top_builddir = ../.. include $(top_builddir)/src/Makefile.global override CPPFLAGS := -I$(top_builddir)/src/port -DFRONTEND $(CPPFLAGS) +override CFLAGS := -fPIC LIBS += $(PTHREAD_LIBS) OBJS = $(LIBOBJS) $(PG_CRC32C_OBJS) chklocale.o erand48.o inet_net_ntop.o \ borg.lerctr.org /home/ler/Git/postgresql/src/port $ Is that more acceptable? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: peripatus build failures....
On Thu, Jul 05, 2018 at 07:47:39AM -0500, Larry Rosenman wrote:
> On Wed, Jul 04, 2018 at 08:37:40PM -0500, Larry Rosenman wrote:
> > On Wed, Jul 04, 2018 at 08:19:48PM -0500, Larry Rosenman wrote:
> > > On Thu, Jul 05, 2018 at 12:56:49PM +1200, Thomas Munro wrote:
> > > > On Thu, Jul 5, 2018 at 12:35 PM, Larry Rosenman wrote:
> > > > > I agree. Is there an easy way I can add this work around to
> > > > > peripatus'
> > > > > source tree:
> > > > >
> > > > > It may be that adding "LDFLAGS+= -Wl,-z,notext" (and removing
> > > > > LLD_UNSAFE) will let the port build with lld.
> > > >
> > > > Maybe something like this at the end of your build-farm.conf?
> > > >
> > > > if ($branch =~ /^REL(9|_10)/)
> > > > {
> > > > $conf{config_env}->{"LDFLAGS"} = "...something something...";
> > > > }
> > > >
> > >
> > > Good news. I ran a quick build test on my checked out FreeBSD ports
> > > tree and with Ed Maste's suggestion, it builds.
> > >
> > > Ed's suggestion:
> > > remove LLD_UNSAFE, and add to the LDFLAGS+= line in the port
> > > -Wl,-z,notext.
> > >
> > > So, that is indeed a fix for us. My question is:
> > > how to add this LDFLAG for FreeBSD >= 12 and PostgreSQL <= 11's configure
> > > et al
> > >
> > > I'm more than willing to try and generate a patch, but would like some
> > > guidance. I'm also willing to give access to my box.
> > >
> > >
> >
> > I also filed FreeBSD pr
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229523 to make the
> > change in the FreeBSD port.
> >
>
> I suspect HEAD and REL_11 are ok due to changes in the pgport source.
> (Someone with better git foo would have to check that).
>
>
anyone want to look at this, or at least give me a clue on how to add
this to 10 & below?
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
signature.asc
Description: PGP signature
Re: "interesting" issue with restore from a pg_dump with a database-wide search_path
On Fri, Jul 06, 2018 at 11:35:41AM -0700, Joshua D. Drake wrote:
> On 07/06/2018 11:27 AM, Larry Rosenman wrote:
> > when I pg_dump -Fc the database and then try to restore it after a
> > create database, I get errors. To get a clean restare I need to do:
>
> Knowing the errors would be helpful.
>
> jD
ler=# drop database wm_common;create database wm_common
DROP DATABASE
ler-# ;
CREATE DATABASE
ler=# \q
borg.lerctr.org /home/ler $ pg_restore -d wm_common wm_t
borg.lerctr.org /home/ler $ cd WM
borg.lerctr.org /home/ler/WM $ pg_restore -d wm_common wm_test.dump
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 12; 3079 887963 EXTENSION
postgis_tiger_geocoder
pg_restore: [archiver (db)] could not execute query: ERROR: function
soundex(character varying) does not exist
HINT: No function matches the given name and argument types. You might need to
add explicit type casts.
Command was: CREATE EXTENSION IF NOT EXISTS postgis_tiger_geocoder WITH
SCHEMA tiger;
pg_restore: [archiver (db)] Error from TOC entry 5400; 0 0 COMMENT EXTENSION
postgis_tiger_geocoder
pg_restore: [archiver (db)] could not execute query: ERROR: extension
"postgis_tiger_geocoder" does not exist
Command was: COMMENT ON EXTENSION postgis_tiger_geocoder IS 'PostGIS tiger
geocoder and reverse geocoder';
pg_restore: [archiver (db)] Error from TOC entry 11; 3079 887754 EXTENSION
postgis_topology
pg_restore: [archiver (db)] could not execute query: ERROR: type "geometry"
does not exist
Command was: CREATE EXTENSION IF NOT EXISTS postgis_topology WITH SCHEMA
topology;
pg_restore: [archiver (db)] Error from TOC entry 5401; 0 0 COMMENT EXTENSION
postgis_topology
pg_restore: [archiver (db)] could not execute query: ERROR: extension
"postgis_topology" does not exist
Command was: COMMENT ON EXTENSION postgis_topology IS 'PostGIS topology
spatial types and functions';
>
>
> > ---
> > \set DB `echo ${DB}`
> > CREATE SCHEMA IF NOT EXISTS postgis;
> > CREATE SCHEMA IF NOT EXISTS topology;
> > CREATE SCHEMA IF NOT EXISTS tiger;
> > SET search_path=public,postgis,tiger,topology;
> > ALTER DATABASE :DB SET search_path=public,postgis,tiger,topology;
> > \c
> > CREATE EXTENSION fuzzystrmatch schema postgis;
> > -- Enable PostGIS (includes raster)
> > CREATE EXTENSION postgis schema postgis;
> > -- Enable Topology
> > CREATE EXTENSION postgis_topology schema topology;
> > -- Enable PostGIS Advanced 3D
> > -- and other geoprocessing algorithms
> > CREATE EXTENSION postgis_sfcgal schema postgis;
> > -- rule based standardizer
> > CREATE EXTENSION address_standardizer schema postgis;
> > -- example rule data set
> > CREATE EXTENSION address_standardizer_data_us schema postgis;
> > -- Enable US Tiger Geocoder
> > CREATE EXTENSION postgis_tiger_geocoder schema tiger;
> > -- routing functionality
> > CREATE EXTENSION pgrouting schema postgis;
> > -- spatial foreign data wrappers
> > CREATE EXTENSION ogr_fdw schema postgis;
> > -- LIDAR support
> > CREATE EXTENSION pointcloud schema postgis;
> > -- LIDAR Point cloud patches to geometry type cases
> > CREATE EXTENSION pointcloud_postgis schema postgis;
> >
> > Is the need to do this expected?
> >
> > This is 10.4 on FreeBSD.
> >
> >
> >
>
> --
> Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
> *** A fault and talent of mine is to tell it exactly how it is. ***
> PostgreSQL centered full stack support, consulting and development.
> Advocate: @amplifypostgres || Learn: https://postgresconf.org
> * Unless otherwise stated, opinions are my own. *
>
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
signature.asc
Description: PGP signature
"interesting" issue with restore from a pg_dump with a database-wide search_path
I have the following:
\set DB `echo $DB`
CREATE SCHEMA IF NOT EXISTS postgis;
CREATE SCHEMA IF NOT EXISTS topology;
CREATE SCHEMA IF NOT EXISTS tiger;
SET search_path=public,postgis,tiger,topology;
ALTER DATABASE :DB SET search_path=public,postgis,tiger,topology;
\c wm_test
CREATE EXTENSION fuzzystrmatch schema postgis;
-- Enable PostGIS (includes raster)
CREATE EXTENSION postgis schema postgis;
-- Enable Topology
CREATE EXTENSION postgis_topology schema topology;
-- Enable PostGIS Advanced 3D
-- and other geoprocessing algorithms
CREATE EXTENSION postgis_sfcgal schema postgis;
-- rule based standardizer
CREATE EXTENSION address_standardizer schema postgis;
-- example rule data set
CREATE EXTENSION address_standardizer_data_us schema postgis;
-- Enable US Tiger Geocoder
CREATE EXTENSION postgis_tiger_geocoder schema tiger;
-- routing functionality
CREATE EXTENSION pgrouting schema postgis;
-- spatial foreign data wrappers
CREATE EXTENSION ogr_fdw schema postgis;
-- LIDAR support
CREATE EXTENSION pointcloud schema postgis;
-- LIDAR Point cloud patches to geometry type cases
CREATE EXTENSION pointcloud_postgis schema postgis;
-
when I pg_dump -Fc the database and then try to restore it after a
create database, I get errors. To get a clean restare I need to do:
---
\set DB `echo ${DB}`
CREATE SCHEMA IF NOT EXISTS postgis;
CREATE SCHEMA IF NOT EXISTS topology;
CREATE SCHEMA IF NOT EXISTS tiger;
SET search_path=public,postgis,tiger,topology;
ALTER DATABASE :DB SET search_path=public,postgis,tiger,topology;
\c
CREATE EXTENSION fuzzystrmatch schema postgis;
-- Enable PostGIS (includes raster)
CREATE EXTENSION postgis schema postgis;
-- Enable Topology
CREATE EXTENSION postgis_topology schema topology;
-- Enable PostGIS Advanced 3D
-- and other geoprocessing algorithms
CREATE EXTENSION postgis_sfcgal schema postgis;
-- rule based standardizer
CREATE EXTENSION address_standardizer schema postgis;
-- example rule data set
CREATE EXTENSION address_standardizer_data_us schema postgis;
-- Enable US Tiger Geocoder
CREATE EXTENSION postgis_tiger_geocoder schema tiger;
-- routing functionality
CREATE EXTENSION pgrouting schema postgis;
-- spatial foreign data wrappers
CREATE EXTENSION ogr_fdw schema postgis;
-- LIDAR support
CREATE EXTENSION pointcloud schema postgis;
-- LIDAR Point cloud patches to geometry type cases
CREATE EXTENSION pointcloud_postgis schema postgis;
Is the need to do this expected?
This is 10.4 on FreeBSD.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
signature.asc
Description: PGP signature
Re: peripatus build failures....
On Wed, Jul 04, 2018 at 08:37:40PM -0500, Larry Rosenman wrote:
> On Wed, Jul 04, 2018 at 08:19:48PM -0500, Larry Rosenman wrote:
> > On Thu, Jul 05, 2018 at 12:56:49PM +1200, Thomas Munro wrote:
> > > On Thu, Jul 5, 2018 at 12:35 PM, Larry Rosenman wrote:
> > > > I agree. Is there an easy way I can add this work around to peripatus'
> > > > source tree:
> > > >
> > > > It may be that adding "LDFLAGS+= -Wl,-z,notext" (and removing
> > > > LLD_UNSAFE) will let the port build with lld.
> > >
> > > Maybe something like this at the end of your build-farm.conf?
> > >
> > > if ($branch =~ /^REL(9|_10)/)
> > > {
> > > $conf{config_env}->{"LDFLAGS"} = "...something something...";
> > > }
> > >
> >
> > Good news. I ran a quick build test on my checked out FreeBSD ports
> > tree and with Ed Maste's suggestion, it builds.
> >
> > Ed's suggestion:
> > remove LLD_UNSAFE, and add to the LDFLAGS+= line in the port
> > -Wl,-z,notext.
> >
> > So, that is indeed a fix for us. My question is:
> > how to add this LDFLAG for FreeBSD >= 12 and PostgreSQL <= 11's configure
> > et al
> >
> > I'm more than willing to try and generate a patch, but would like some
> > guidance. I'm also willing to give access to my box.
> >
> >
>
> I also filed FreeBSD pr
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229523 to make the
> change in the FreeBSD port.
>
I suspect HEAD and REL_11 are ok due to changes in the pgport source.
(Someone with better git foo would have to check that).
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
signature.asc
Description: PGP signature
Re: peripatus build failures....
On Wed, Jul 04, 2018 at 08:19:48PM -0500, Larry Rosenman wrote:
> On Thu, Jul 05, 2018 at 12:56:49PM +1200, Thomas Munro wrote:
> > On Thu, Jul 5, 2018 at 12:35 PM, Larry Rosenman wrote:
> > > I agree. Is there an easy way I can add this work around to peripatus'
> > > source tree:
> > >
> > > It may be that adding "LDFLAGS+= -Wl,-z,notext" (and removing LLD_UNSAFE)
> > > will let the port build with lld.
> >
> > Maybe something like this at the end of your build-farm.conf?
> >
> > if ($branch =~ /^REL(9|_10)/)
> > {
> > $conf{config_env}->{"LDFLAGS"} = "...something something...";
> > }
> >
>
> Good news. I ran a quick build test on my checked out FreeBSD ports
> tree and with Ed Maste's suggestion, it builds.
>
> Ed's suggestion:
> remove LLD_UNSAFE, and add to the LDFLAGS+= line in the port
> -Wl,-z,notext.
>
> So, that is indeed a fix for us. My question is:
> how to add this LDFLAG for FreeBSD >= 12 and PostgreSQL <= 11's configure et
> al
>
> I'm more than willing to try and generate a patch, but would like some
> guidance. I'm also willing to give access to my box.
>
>
I also filed FreeBSD pr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229523 to make the
change in the FreeBSD port.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
signature.asc
Description: PGP signature
Re: peripatus build failures....
On Thu, Jul 05, 2018 at 12:56:49PM +1200, Thomas Munro wrote:
> On Thu, Jul 5, 2018 at 12:35 PM, Larry Rosenman wrote:
> > I agree. Is there an easy way I can add this work around to peripatus'
> > source tree:
> >
> > It may be that adding "LDFLAGS+= -Wl,-z,notext" (and removing LLD_UNSAFE)
> > will let the port build with lld.
>
> Maybe something like this at the end of your build-farm.conf?
>
> if ($branch =~ /^REL(9|_10)/)
> {
> $conf{config_env}->{"LDFLAGS"} = "...something something...";
> }
>
Good news. I ran a quick build test on my checked out FreeBSD ports
tree and with Ed Maste's suggestion, it builds.
Ed's suggestion:
remove LLD_UNSAFE, and add to the LDFLAGS+= line in the port
-Wl,-z,notext.
So, that is indeed a fix for us. My question is:
how to add this LDFLAG for FreeBSD >= 12 and PostgreSQL <= 11's configure et al
I'm more than willing to try and generate a patch, but would like some
guidance. I'm also willing to give access to my box.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
signature.asc
Description: PGP signature
Re: peripatus build failures....
On Wed, Jul 04, 2018 at 07:35:28PM -0500, Larry Rosenman wrote: > On Thu, Jul 05, 2018 at 12:30:37PM +1200, Thomas Munro wrote: > > On Thu, Jul 5, 2018 at 11:43 AM, Larry Rosenman wrote: > > > I noticed my buildfarm member peripatus hadn't been building due to me > > > missing a perl library. After I fixed that I get failures on: > > > > > > Buildfarm member peripatus failed on REL9_3_STABLE stage Make > > > Buildfarm member peripatus failed on REL9_4_STABLE stage Make > > > Buildfarm member peripatus failed on REL9_5_STABLE stage Make > > > Buildfarm member peripatus failed on REL9_6_STABLE stage Make > > > Buildfarm member peripatus failed on REL_10_STABLE stage Make > > > > > > HEAD and REL_11_STABLE build fine. > > > > > > These all fail on relocation issues in pgport(strcase*) and possibly > > > others. > > > > > > This is FreeBSD HEAD as of today, clang 6.0.1, lld as the linker. > > > > > > Can someone take a look at these? > > > I've tried making sure all the cache's are clear, etc, same results. > > > > Seems to have something to do with the recent linker toolchain changes > > in FreeBSD. I don't actually understand what's going on here or why > > it doesn't affect REL_11_STABLE and HEAD, but this seems to be some > > kind of explanation + workaround (as used by the ports): > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219758 > > https://svnweb.freebsd.org/ports?view=revision=456635 > > > I agree. Is there an easy way I can add this work around to peripatus' > source tree: > > It may be that adding "LDFLAGS+= -Wl,-z,notext" (and removing LLD_UNSAFE) > will let the port build with lld. > > Thanks, Thomas. BTW: If some hacker wants to play on this box, I'm happy to make an account and give ssh access. It's a playground. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: peripatus build failures....
On Thu, Jul 05, 2018 at 12:30:37PM +1200, Thomas Munro wrote: > On Thu, Jul 5, 2018 at 11:43 AM, Larry Rosenman wrote: > > I noticed my buildfarm member peripatus hadn't been building due to me > > missing a perl library. After I fixed that I get failures on: > > > > Buildfarm member peripatus failed on REL9_3_STABLE stage Make > > Buildfarm member peripatus failed on REL9_4_STABLE stage Make > > Buildfarm member peripatus failed on REL9_5_STABLE stage Make > > Buildfarm member peripatus failed on REL9_6_STABLE stage Make > > Buildfarm member peripatus failed on REL_10_STABLE stage Make > > > > HEAD and REL_11_STABLE build fine. > > > > These all fail on relocation issues in pgport(strcase*) and possibly > > others. > > > > This is FreeBSD HEAD as of today, clang 6.0.1, lld as the linker. > > > > Can someone take a look at these? > > I've tried making sure all the cache's are clear, etc, same results. > > Seems to have something to do with the recent linker toolchain changes > in FreeBSD. I don't actually understand what's going on here or why > it doesn't affect REL_11_STABLE and HEAD, but this seems to be some > kind of explanation + workaround (as used by the ports): > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219758 > https://svnweb.freebsd.org/ports?view=revision=456635 > I agree. Is there an easy way I can add this work around to peripatus' source tree: It may be that adding "LDFLAGS+= -Wl,-z,notext" (and removing LLD_UNSAFE) will let the port build with lld. Thanks, Thomas. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
peripatus build failures....
I noticed my buildfarm member peripatus hadn't been building due to me missing a perl library. After I fixed that I get failures on: Buildfarm member peripatus failed on REL9_3_STABLE stage Make Buildfarm member peripatus failed on REL9_4_STABLE stage Make Buildfarm member peripatus failed on REL9_5_STABLE stage Make Buildfarm member peripatus failed on REL9_6_STABLE stage Make Buildfarm member peripatus failed on REL_10_STABLE stage Make HEAD and REL_11_STABLE build fine. These all fail on relocation issues in pgport(strcase*) and possibly others. This is FreeBSD HEAD as of today, clang 6.0.1, lld as the linker. Can someone take a look at these? I've tried making sure all the cache's are clear, etc, same results. Thanks. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
