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 1igr45-0006kK-3F for pgsql-bugs@arkaria.postgresql.org; Mon, 16 Dec 2019 14:09:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1igr43-0006iP-JJ for pgsql-bugs@arkaria.postgresql.org; Mon, 16 Dec 2019 14:09:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1igr43-0006iI-4g for pgsql-bugs@lists.postgresql.org; Mon, 16 Dec 2019 14:09:35 +0000 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1igr3w-00024v-Ds for pgsql-bugs@lists.postgresql.org; Mon, 16 Dec 2019 14:09:33 +0000 Received: by mail-wr1-x42d.google.com with SMTP id c14so7427573wrn.7 for ; Mon, 16 Dec 2019 06:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=M11ZtB6F8LKBdCuksrzr98DXinFRnLJHSLHrEhYb6Rc=; b=J/FkGiE2G2sUuz2QiUk8LHvSKlo/W9dlBeh2jcWR/mvU4OorycssrWxYqz2b7ZOIAo poOFNvDL62wE3B9HWGwox+4jrHZFs6ho1Q9P5fWwCFZ+Gh0H8tg5iYC1g9fNH85bKgRA YIOiepMZJggNXFdokYNF0ZO1nrp5Mhkj5K9wTRPEJUp+GVUzMYTN8dfZEkBKrRx/76ze Oh4BkIUGJCjAdqrkQXE5Tf9iR2f6GBWKKzCoA5akvjQOxHp/SmgdI1LQ6p+f0tnYtAlb MP6CjvYVq8iCUulGO6QEqstrtssbtupsKjTx8n5Bp6QeMRHuBNW8ArjbYW6hG+5dPxvT llSw== 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; bh=M11ZtB6F8LKBdCuksrzr98DXinFRnLJHSLHrEhYb6Rc=; b=kLEVqXPNNLzXp5dADJsbL/u3BVQOFKtJ4UnYJ82sTbHloJZlQjSZYxn+B1522vf1Ab pzxGCvcEztJDNRSNxR26mCTwE7ZNb9Y31n63SzHGHpizcmbdy1Dcn9MIzVfHFgVBonjR ROWGzkpaTAZ2X0r2pbsLmJ/yoZpEGTnc0k6dKNA6j/E/ljEFaJCHJ2d03VYdS1zKmiWA SX+OdZ+ckcGivR1Dio/ad+FXRsqmtwtscBknjP30MrkDQNCMVaxTHq/75PmgHGkNO3QZ 3bFMzOdnT97Nx83hRTBXoK/Ci0ORPDkP5diWp9eoE67EbRar5GLqoRf21Ts+LCd/H6Sk 2sJg== X-Gm-Message-State: APjAAAUD7Z3Uu+CMMnEfUvfMo3Ht8JWIkXwn9gyVrMEtxYZDefTHwLzr lH2nVYyLv75vl8Mu+kZvNh1tYg== X-Google-Smtp-Source: APXvYqxFvIZvlXbWPymMgJxsUZIEZj+QlDKcTr9OsGRePST3OqWzdPZskmK7Bt6NpYojhVJw2bm5HA== X-Received: by 2002:a5d:6406:: with SMTP id z6mr28867536wru.294.1576505366225; Mon, 16 Dec 2019 06:09:26 -0800 (PST) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id z11sm22004474wrt.82.2019.12.16.06.09.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Dec 2019 06:09:25 -0800 (PST) Date: Mon, 16 Dec 2019 15:09:22 +0100 From: Tomas Vondra To: Thomas Munro Cc: Alvaro Herrera , Andres Freund , James Coleman , PostgreSQL mailing lists Subject: Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash Message-ID: <20191216140922.pmjrkvt5o6rkhpuw@development> References: <20191203170704.GA28076@alvherre.pgsql> <20191210173224.y5vaam6ep7pjmddt@development> <20191214133912.effa4k2pwjnmplej@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20191214133912.effa4k2pwjnmplej@development> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sat, Dec 14, 2019 at 02:39:12PM +0100, Tomas Vondra wrote: >On Sat, Dec 14, 2019 at 05:01:05PM +1300, Thomas Munro wrote: >>On Wed, Dec 11, 2019 at 6:32 AM Tomas Vondra >> wrote: >>>The annoying thing is that it's the workers that crash, and the leader >>>failed to notice that, so it was waiting in WaitForParallelWorkersToExit >>>forever. Not sure what the issue is. >> >>That's bad. Some edge case in >>WaitForBackgroundWorkerShutdown()/GetBackgroundWorkerPid() that is >>b0rked perhaps? Can you reproduce it, and tell us what the stack >>looks like, maybe on a new thread? > >Sure. I'll try reproducing it and get this extra info. I was planning to >do that, but then I lost the data for the report because of a silly >mistake. Early next week, hopefully. > I've tried reproducing this, but so far no luck. I've only managed to do two runs, though, because this particular machine only has space for the 1TB of temp files on spinning rust. I wonder if it's possible to reproduce the issue with a smaller data set? I've tried using smaller work_mem, but then it does not trigger the issue :-( regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services