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 1gsDcz-0003Jd-4T for pgsql-general@arkaria.postgresql.org; Fri, 08 Feb 2019 21:24:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gsDcx-0003FA-SQ for pgsql-general@arkaria.postgresql.org; Fri, 08 Feb 2019 21:24:03 +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 1gsDcv-0003Ev-Sf for pgsql-general@lists.postgresql.org; Fri, 08 Feb 2019 21:24:03 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gsDcr-0002Xw-LJ for pgsql-general@postgresql.org; Fri, 08 Feb 2019 21:24:00 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9C21F21924; Fri, 8 Feb 2019 16:23:56 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Fri, 08 Feb 2019 16:23:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=L 91fYzg6TPxFs4RbgjxU4PsU6J4KkExhVRbBEgbhIbk=; b=rPwJUckEfGSTYGZxK zwaSIGFBhaw5A4MjMbVnZcCZyd6Mde5NoR2MtMi5SaKDSOeLo9xbG4Pfju9+gwJe ZoBRh8ZTB/ueWM7A5cRpq+NIXShd5h6vF1FhFKq1l1wghImHUuW2YHsEu25jukBn t6WfhlnD/DPhOevCQdxX0gU1Bp1+7qFvk1vv0xCy+BPEBQLUZp2o6PSxC7TLO74k GkLz0yuW4NMZ/DYuxrX5J5nQbMcHLqOt0ovjkm9l4My0LmZWUL0kOgHoRXhdzD2S PXip9s7FAyiQP71tmSmPYBL2uC2MIdinD6UHaeNOB9I2c8XO2R+xt0mF/xZPlbw+ F029g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=L91fYzg6TPxFs4RbgjxU4PsU6J4KkExhVRbBEgbhI bk=; b=8V15pAXMD0VqW3QUgdrmZrVzjRHme4Zu5b9Q0prjJe9Xu1dUHOhfPtrzM Ou15ah1fDVeD71Bk40/zXXBK0QRASV63YVSthH8teSnMCVKrmw0AEzRjJtsgSofV kTWo4XOwPyIa1F4r6PAF8QodbUktjEGW5tve3qJc8KBZq0RkbaGPtQD120Usfjej fWizGLSK54/ILsPgW/VZJ7sBipM0UMS9Uo7UxFslujI/VApdFY7yyAsxdzPsJAz/ Odgm8jddoD4pPsKQr49ikFSxqwWYnfjnnNmKWeP1J1Nit2AKs4vbDW8FgdzEcEFl re8dTHlJ5yZfhxh+0MHwb9hVCNrDQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrledvgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomh eptegurhhirghnucfmlhgrvhgvrhcuoegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghv vghrrdgtohhmqeenucffohhmrghinhepphhoshhtghhrvghsqhhlrdhorhhgnecukfhppe ejuddrvdduvddrudehtddrvddtvdenucfrrghrrghmpehmrghilhhfrhhomheprggurhhi rghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomhenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: from [192.168.1.4] (unknown [71.212.150.202]) by mail.messagingengine.com (Postfix) with ESMTPA id 84867100BA; Fri, 8 Feb 2019 16:23:55 -0500 (EST) Subject: Re: Server goes to Recovery Mode when run a SQL To: PegoraroF10 , pgsql-general@postgresql.org References: <1549209182255-0.post@n3.nabble.com> <1549209942200-0.post@n3.nabble.com> <1549660293178-0.post@n3.nabble.com> From: Adrian Klaver Message-ID: <4f05eb46-78d3-7262-1ebd-c12d4e696daf@aklaver.com> Date: Fri, 8 Feb 2019 13:23:54 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <1549660293178-0.post@n3.nabble.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2/8/19 1:11 PM, PegoraroF10 wrote: > *Well, now we have two queries which stops completelly our postgres server. > That problem occurs on 10.6 and 11.1 versions. > On both server the problem is the same. * > *Linux Log of new crash, which takes several minutes to stop:* > > Feb 8 15:06:40 fxReplicationServer kernel: [1363901.643121] postgres invoked oom-killer: gfp_mask=0x24280ca, order=0, oom_score_adj=0 So the oom-killer kicked in. See below for some ways to deal with this: https://www.postgresql.org/docs/10/kernel-resources.html > *And this new query which stops the server too but differently because > the old one stops immediatelly instead of this, as you can see images.* > > *This query runs for aproximately 5 minutes. See link above with images > and logs and you´ll see how memory will grow. Memory use starts with 8gb > e grows until use them all. When all memory is in use then it starts to > swap. When all swap is allocated then it gets the "out of memory" and > stops completelly. You'll see that this query has generate_series, with, > recursive and lateral statements. It was bad written because that > generate_series generates a enormous quantity of records, probably > millions of them. But a wrong query couldn´t stop the entire server, > could ?* You run anything(computer related or otherwise) out of resources and bad things are going to happen. -- Adrian Klaver adrian.klaver@aklaver.com