Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h250r-0005FX-TU for pgsql-admin@arkaria.postgresql.org; Fri, 08 Mar 2019 02:13:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h250q-0007Bb-GF for pgsql-admin@arkaria.postgresql.org; Fri, 08 Mar 2019 02:13:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h250q-0007BU-8S for pgsql-admin@lists.postgresql.org; Fri, 08 Mar 2019 02:13:28 +0000 Received: from uucp.dinoex.org ([2a0b:f840::12] helo=uucp.dinoex.sub.de) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h250n-0000ZX-GB for pgsql-admin@postgresql.org; Fri, 08 Mar 2019 02:13:27 +0000 Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id x282D5IF091857 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Mar 2019 03:13:06 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id x282D5e1091856; Fri, 8 Mar 2019 03:13:05 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id x281MnxT084095; Fri, 8 Mar 2019 02:22:49 +0100 (CET) (envelope-from peter@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id x281KCfD083939; Fri, 8 Mar 2019 02:20:13 +0100 (CET) (envelope-from peter@gate.oper.dinoex.org) Received: (from peter@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id x281KCYI083938; Fri, 8 Mar 2019 02:20:12 +0100 (CET) (envelope-from peter) Date: Fri, 8 Mar 2019 02:20:12 +0100 From: Peter To: pgsql-admin@postgresql.org Cc: pgsql@FreeBSD.org Subject: Re: Upgrade 10.5->10.6 : db crash BUS ERROR (sig 10), reproducible Message-ID: <20190308012012.GA49481@gate.oper.dinoex.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.1 (2018-12-01) X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de;) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Fri, 08 Mar 2019 03:13:09 +0100 (CET) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi Tom, Andrew, much thanks for the replies! Alright, lets fill in some concrete data: > I'm assuming from the CC that this is on FreeBSD, but on what > architecture? When on my evening errands I recognized that I should have mentioned this - FreeBSD is correct; it is built on amd64 for i386, and run on i386. Version: FreeBSD 11.2-RELEASE-p9 #0 r343946M#C51:82 Build-Options: OPTIONS_FILE_UNSET+=DEBUG OPTIONS_FILE_UNSET+=DOCS OPTIONS_FILE_UNSET+=DTRACE OPTIONS_FILE_SET+=GSSAPI OPTIONS_FILE_SET+=INTDATE OPTIONS_FILE_UNSET+=LDAP OPTIONS_FILE_SET+=NLS OPTIONS_FILE_UNSET+=OPTIMIZED_CFLAGS OPTIONS_FILE_UNSET+=PAM OPTIONS_FILE_SET+=SSL OPTIONS_FILE_SET+=TZDATA OPTIONS_FILE_SET+=XML Extra Compiler-Options: -march=pentium3 Init-Options: --data-checksums --encoding=utf-8 --lc-collate=de_DE.UTF-8 --lc-ctype=de_DE.UTF-8 --lc-messages=en_US.UTF-8 --lc-monetary=en_US.UTF-8 --lc-numeric=en_US.UTF-8 --lc-time=en_US.UTF-8 Run-Options: -w -m fast -o --config_file=/usr/local/etc/postgresql/postgresql.conf Furthermore, FreeBSD did impose a change for R. 10.6: it forces the use of gcc on i386 (gcc-8 in this case). Earlier versions were built with system compiler Clang. The commitlog says this about the matter: ! r484807 | girgen | 2018-11-12 16:54:19 +0100 (Mon, 12 Nov 2018) | 5 lines ! ! Fix build problems on i386 ! ! Use GCC seems to be proper way to do it. SSE2 would not be available ! for all CPU:s. > Did it drop a core file (look in the data dir for postgres.core) and if > so can you get a backtrace? Looking... yes, there is a core. Lets grab a first-fault core, as that one obviousely is from the failed recover: ! (gdb) core postgres.core.1st ! Core was generated by `postgres: bgworker: parallel worker for PID 68755 '. ! Program terminated with signal 10, Bus error. ! Reading symbols from ! #0 0x0838bdf2 in pg_checksum_page () ! (gdb) bt ! #0 0x0838bdf2 in pg_checksum_page () ! #1 0x0838a2b8 in PageIsVerified () ! #2 0x5a824500 in ?? () ! #3 0x00000000 in ?? () The second one looks this way: ! (gdb) core postgres.core ! Core was generated by `postgres: startup process recovering 000000010000002C000000C6'. ! Program terminated with signal 10, Bus error. ! Reading symbols from ! #0 0x0838bdf2 in pg_checksum_page () ! (gdb) bt ! #0 0x0838bdf2 in pg_checksum_page () ! #1 0x0838a2b8 in PageIsVerified () ! #2 0x59e14500 in ?? () ! #3 0x00000000 in ?? () Anything more I can do here? (Advice on how to build with debugging support is appreciated.) > You can check whether your CPU supports SSE2 by looking at the Features= > line in /var/run/dmesg.boot. It seems unlikely that it does not, because > SSE2 was introduced in 2000 with the Pentium 4. No need to check; I am absolutely certain that it does NOT. https://www.asus.com/supportonly/CUV4X-DLS/HelpDesk_CPU/ But, Your explanation seems not to answer the fundamental question: if the database at 10.6 is still supposed to be able to run without SSE2? > It seems pretty unlikely that that'd have anything to do with a > bus-error failure, anyway. But this report contains far too little > information to let anyone do anything but speculate. Whateever information You like to have, just ask and I will gladly do my best to obtain it, as I get around. (This is a reproducible on a very well maintained piece of software - this is rather fun.) Some more experiments & observations: The crash happens at a specific query - I get parse,bind, but no execute timing. Furthermore, when I try and set ! max_parallel_workers_per_gather = 0 then the query goes thru and delivers proper results. But then after few minutes I get this one: ! postgres[71256]: [8-1] :[] LOG: 00000: checkpointer process (PID 71258) ! was terminated by signal 10: Bus error Different approach, same result: ! dynamic_shared_memory_type = posix -> crash immediate ! dynamic_shared_memory_type = sysv -> crash immediate ! dynamic_shared_memory_type = mmap -> crash immediate ! dynamic_shared_memory_type = none -> crash later in checkpointer regards, PMc