Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fAfjr-00072Q-Bh for pgsql-admin@arkaria.postgresql.org; Mon, 23 Apr 2018 17:58:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fAfjp-0000lc-OD for pgsql-admin@arkaria.postgresql.org; Mon, 23 Apr 2018 17:58:53 +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.89) (envelope-from ) id 1fAfjp-0000lS-4O for pgsql-admin@lists.postgresql.org; Mon, 23 Apr 2018 17:58:53 +0000 Received: from resqmta-ch2-12v.sys.comcast.net ([2001:558:fe21:29:69:252:207:44]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fAfjl-0004uO-AG for pgsql-admin@postgresql.org; Mon, 23 Apr 2018 17:58:52 +0000 Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id AeWIfpOYInaCsAfjefqvvv; Mon, 23 Apr 2018 17:58:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1524506322; bh=lfviSTkTv1vItDJ6gFV70rNiK7H5CbNzk0kCLiiUKWA=; h=Received:Received:Received:From:To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=XwD7tC3jj78BB/4iNhYkijAayKsScx9erfzTPbEhBSCmSxzjMXMY57aZDfl0zGH6h zELYxTeAnlJ6wWUc+Gm3N5lEMvhrVXyx3UF5cNKaCj8QoDlPjUYzW8zfwqOSKGngZl z8/zMqkEz3FLW4T9OYFjs2AeqggVbevjf/rpnUc1GFPCnyJqlMZMbzbdHUj/fncqQ4 FiCLe6HWN1rUGZ563gx0bLPilauwOT9b5YCkydJ8wghFXbwqUn2Aw2FCXXkt0UojH2 SbGG9tQ6/TN4YSglY0f242Q+7CMzGMPCUALG4hbj6FRfj29mLnp/Scd3y0Fn+Pclq8 Wqoydtuy7dyaA== Received: from jsievers.comcast.net ([12.187.116.132]) by resomta-ch2-02v.sys.comcast.net with ESMTPA id AfjUfYgif0enUAfjWfGp1c; Mon, 23 Apr 2018 17:58:40 +0000 Received: from jsievers.enova.com (localhost [127.0.0.1]) by jsievers.comcast.net (Postfix) with ESMTP id D8E32260056; Mon, 23 Apr 2018 12:58:31 -0500 (CDT) From: Jerry Sievers To: Ron Cc: "pgsql-admin\@postgresql.org" Subject: Re: Health checks after machine crash? References: Date: Mon, 23 Apr 2018 12:58:31 -0500 In-Reply-To: (Ron's message of "Mon, 23 Apr 2018 11:45:58 -0500") Message-ID: <87y3hd4xfc.fsf@jsievers.enova.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4wfPWFu1LHjH4zre8799MsehvSL2QvE3cdJ6tNp7CCQVG/wL51JI0ipiNSdVAid0qakwxt+WjzJubaUEzDR0Dw+JZYcb0ynZ7kWfq+PlowvaFAAUW/kEbu aPcmeE/QsKie2GgK76AAt8809O46Wlvl1mEPEsY0Kvt4R7AEDbMvjLmaQcoVrF6ewnjk8QeqtuycdWsSmWe66m8lLnjLcXMHmWlgYPyXvGg75P4TDYZcZIOr List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Ron writes: > Hi, > > v8.4 (Yes, it's archaic.=C2=A0 Upgrade plan is in progress.) Please do! :-) > What queries should I run against the catalog tables to see whether or > not the cluster is healthy after reboot? Is the cluster confi'd to be at risk of corruption after crash.. such as full_page_write=3Doff, fsync=3Doff? Do your logs show any obvious sign of corruption, bad blocks etc? You may have little to worry about since Pg is very crash tolerant even old versions 8.4 and prior. I'd try vacuum and analyze whole cluster plus dumpall >/dev/null and check for errors there too. Any sort of corruption likely to cause application problems likely to show up in so doing. HTH > Thanks --=20 Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@comcast.net p: 312.241.7800