Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bpapN-00042l-1l for pgsql-performance@arkaria.postgresql.org; Thu, 29 Sep 2016 12:52:41 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bpapM-0003su-EI for pgsql-performance@arkaria.postgresql.org; Thu, 29 Sep 2016 12:52:40 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bpapL-0003sQ-J9 for pgsql-performance@postgresql.org; Thu, 29 Sep 2016 12:52:39 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bpapG-0006ei-3Y for pgsql-performance@postgresql.org; Thu, 29 Sep 2016 12:52:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u8TCqVMA004403; Thu, 29 Sep 2016 08:52:31 -0400 From: Tom Lane To: Cea Stapleton cc: pgsql-performance@postgresql.org, eli@healthfinch.com Subject: Re: Failing Multi-Job Restores, Missing Indexes on Restore In-reply-to: <70774A06-3FD9-42D2-BCCB-0CCC8E8D777F@healthfinch.com> References: <70774A06-3FD9-42D2-BCCB-0CCC8E8D777F@healthfinch.com> Comments: In-reply-to Cea Stapleton message dated "Thu, 29 Sep 2016 07:36:55 -0500" Date: Thu, 29 Sep 2016 08:52:31 -0400 Message-ID: <4402.1475153551@sss.pgh.pa.us> X-Pg-Spam-Score: -4.9 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Cea Stapleton writes: > We are having a baffling problem we hope you might be able to help with. We were hoping to speed up postgres restores to our reporting server. First, we were seeing missing indexes with pg_restore to our reporting server for one of our databases when we did pg_restore with multiple jobs (a clean restore, we also tried dropping the database prior to restore, just in case something was extant and amiss). The indexes missed were not consistent, and we were only ever seeing errors on import that indicated an index had not yet been built. For example: > pg_restore: [archiver (db)] could not execute query: ERROR: index "index_versions_on_item_type_and_item_id" does not exist > Command was: DROP INDEX public.index_versions_on_item_type_and_item_id; Which PG version is that; particularly, which pg_restore version? What's the exact pg_restore command you were issuing? > We decided to move back to a multi-job regular restore, and then the restores began crashing thusly: > [2016-09-14 02:20:36 UTC] LOG: server process (PID 27624) was terminated by signal 9: Killed This is probably the dreaded Linux OOM killer. Fix by reconfiguring your system to disallow memory overcommit, or at least make it not apply to Postgres, cf https://www.postgresql.org/docs/9.5/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance