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 1gSpge-0000pp-6L for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Nov 2018 20:46:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gSpgc-0004Sv-Ro for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Nov 2018 20:46:54 +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 1gSpgc-0004So-Fx for pgsql-hackers@lists.postgresql.org; Fri, 30 Nov 2018 20:46:54 +0000 Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gSpgZ-0008WS-Ne for pgsql-hackers@postgresql.org; Fri, 30 Nov 2018 20:46:53 +0000 Received: by mail-io1-xd44.google.com with SMTP id g8so5602176iop.10 for ; Fri, 30 Nov 2018 12:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WMva6xWhD1OybhX4KP74nXOdaNifw7bANtoYz7vz7As=; b=k8LxJu14Z64Fi/LhSEvwoQku/SqzTVw04Y8cFp6G1IW7MJy8bXfdvhuwMA9KjzV394 +MZtTuDujRXRPA6YPQpZoiYYP07X3zSAqM54OAe44tcwS0lLXyNVzB1BZGn3epomReKq Pe4jPJsMKvKQpznywlAYebHDjDmFVPt7vc2LLWwrT5FYYH81Fx40QEtpQ8zOSCGLtAij luN97hzdmeaPiGdvJ37nI0DKyQefZ4kfI8Vr/YcJk1DEZflL7BZ8nMz9SGxRMQJk4B4K GeJjoXWd61KQS/XpW7MreAy1Bk0W0+r5vEz6SnE6U2/xrPH4tHhDkQ6eeB/8/dx1hlLN VJ1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WMva6xWhD1OybhX4KP74nXOdaNifw7bANtoYz7vz7As=; b=MLp2XBS6Rm9LV+/oPfZ19uJPIWFkUM1gHDkmlqrev4v7BVVbTLm1iRwXARUVumVgUw SI8lTaGO+f+0IQrTkQNTvVtEeyDNfLJ0LKCwQX+baxDLN7CcBGJgc+fPrayiFjpwBKTP MAfNL+qHwt2fa3fDuL3yzLrivmvpVE+vRYsfK3eaU2HQ8XNoT76+k6GQrddeVtXxnRjO EFW2uvtaeRAnTiFLYuYcK+t/UF/R7NSwYKPsAmufJB2XPauoZYojCdpy4wQ584pNYLkB Z62dsU2DYjYx3+VtlIyUB7tYU1XfEi/P9WBgIQfCDWkXnAKgx2ktSVHMdgJtcAEs5b5b TG2w== X-Gm-Message-State: AA+aEWa1PM1jmzr6WUAZlPoxHj8NaGECmNtlw0YEIwm655EMyv5CWWDl NWjVUPbCnP44PLIGkz4WWgoJaQ== X-Google-Smtp-Source: AFSGD/Wz6JHofwCemcdE8yp2g+/AseWRZOiQgfiI+11WnCbhVY81ofrOdy0kryKzx7NmHc0FAso03w== X-Received: by 2002:a6b:3fd7:: with SMTP id m206mr5821951ioa.210.1543610809802; Fri, 30 Nov 2018 12:46:49 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id x99sm104805ita.23.2018.11.30.12.46.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Nov 2018 12:46:49 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id BB8C78021B9; Fri, 30 Nov 2018 14:46:47 -0600 (CST) Date: Fri, 30 Nov 2018 14:46:47 -0600 From: Justin Pryzby To: Jakub Glapa Cc: Thomas Munro , alvherre@2ndquadrant.com, pgsql-hackers@postgresql.org Subject: Re: dsa_allocate() faliure Message-ID: <20181130204647.GK24746@telsasoft.com> References: <20181126184509.gge2vqmlu3twf72h@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Nov 30, 2018 at 08:20:49PM +0100, Jakub Glapa wrote: > In the last days I've been monitoring no segfault occurred but the > das_allocation did. > I'm starting to doubt if the segfault I've found in dmesg was actually > related. The dmesg looks like a real crash, not just OOM. You can hopefully find the timestamp of the segfaults in /var/log/syslog, and compare with postgres logs if they go back far enough. All the postgres processes except the parent would've been restarted at that time. > I've grepped the postgres log for dsa_allocated: > Why do the messages occur sometimes as FATAL and sometimes as ERROR? I believe it may depend if it happens in a parallel worker or the leader. You may get more log detail if you enable CSV logging (although unfortunately as I recall it doesn't indicate it's a parallel worker). You could force it to dump core if you recompile postgres with an assert() (see patch below). You could build an .deb by running dpkg-buildpackage -rfakeroot or similar (i haven't done this in awhile), or you could compile, install, and launch debugging binaries from your homedir (or similar) You'd want to compile the same version (git checkout REL_10_6) and with the proper configure flags..perhaps starting with: ./configure --with-libxml --with-libxslt --enable-debug --prefix=$HOME/src/postgresql.bin --enable-cassert && time make && make install Be careful if you have extensions installed that they still work. Justin --- a/src/backend/utils/mmgr/dsa.c +++ b/src/backend/utils/mmgr/dsa.c @@ -727,4 +727,7 @@ dsa_allocate_extended(dsa_area *area, size_t size, int flags) if (!FreePageManagerGet(segment_map->fpm, npages, &first_page)) + { elog(FATAL, "dsa_allocate could not find %zu free pages", npages); + abort() + }