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 1gcu1l-0006bD-E2 for pgsql-admin@arkaria.postgresql.org; Fri, 28 Dec 2018 15:26:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gcu1j-00061C-TE for pgsql-admin@arkaria.postgresql.org; Fri, 28 Dec 2018 15:26:19 +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 1gcu1j-000615-LS for pgsql-admin@lists.postgresql.org; Fri, 28 Dec 2018 15:26:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gcu1h-0004dX-27 for pgsql-admin@lists.postgresql.org; Fri, 28 Dec 2018 15:26:19 +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 wBSFQELT021519; Fri, 28 Dec 2018 10:26:15 -0500 From: Tom Lane To: wambacher@posteo.de cc: pgsql-admin@lists.postgresql.org Subject: Re: crash during autovacuum In-reply-to: <22fb8ec4-67d8-314a-98db-91e2709106db@posteo.de> References: <22fb8ec4-67d8-314a-98db-91e2709106db@posteo.de> Comments: In-reply-to wambacher@posteo.de message dated "Fri, 28 Dec 2018 11:13:12 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21517.1546010774.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Dec 2018 10:26:14 -0500 Message-ID: <21518.1546010774@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk wambacher@posteo.de writes: > this morning my database crashed, because of a problem during autovacuum= . > this is the second time during the last 2 month and i can't find out why= . Can you get a stack trace from the crash? https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_= backend The evidence may be gone by now for your current crash, but if so, make sure you are prepared to capture info from the next one. The other respondent might be right that this ultimately traces to data corruption, but it's hard to be sure without more info. regards, tom lane