Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eWOee-0000op-7C for pgsql-admin@arkaria.postgresql.org; Tue, 02 Jan 2018 15:39:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eWOed-0004Df-5h for pgsql-admin@arkaria.postgresql.org; Tue, 02 Jan 2018 15:39:03 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eWOec-0004DQ-Om for pgsql-admin@lists.postgresql.org; Tue, 02 Jan 2018 15:39:02 +0000 Received: from smtprelay0171.b.hostedemail.com ([64.98.42.171] helo=smtprelay.b.hostedemail.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eWOeZ-0000G4-FE for pgsql-admin@lists.postgresql.org; Tue, 02 Jan 2018 15:39:01 +0000 Received: from filter.hostedemail.com (10.5.19.248.rfc1918.com [10.5.19.248]) by smtprelay05.b.hostedemail.com (Postfix) with ESMTP id B403432B051; Tue, 2 Jan 2018 15:38:57 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Spam-Summary: 50,0,0,,d41d8cd98f00b204,alvherre@alvh.no-ip.org,:::,RULES_HIT:41:355:379:599:800:967:973:988:989:1260:1277:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1541:1593:1594:1595:1596:1711:1730:1747:1777:1792:2393:2525:2560:2563:2682:2685:2689:2690:2828:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4384:4605:5007:6119:6261:7903:8603:9025:9121:10004:10400:10848:11232:11658:11914:12043:12296:12555:12663:12986:13069:13311:13357:13439:13891:13894:13895:14130:14181:14721:14764:21080:21324:21450:21451:21627:30054:30069:30070,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:3,LUA_SUMMARY:none X-HE-Tag: slip99_4e2b051a6c33c X-Filterd-Recvd-Size: 2409 Received: from alvin.alvh.no-ip.org (unknown [179.57.113.18]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf12.b.hostedemail.com (Postfix) with ESMTPA; Tue, 2 Jan 2018 15:38:57 +0000 (UTC) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 40B067CC; Tue, 2 Jan 2018 12:38:54 -0300 (-03) Date: Tue, 2 Jan 2018 12:38:54 -0300 From: Alvaro Herrera To: flumbador@virgilio.it Cc: pgsql-admin@lists.postgresql.org Subject: Re: Issue on restore / recover Message-ID: <20180102153854.nldw2ouxnehtp63k@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <524817289.230206.1514560886805@mail.virgilio.it> User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk flumbador@virgilio.it wrote: > During the restore 3 files were missing; these three files belong to a table with high transaction workload, and for sure during the backup many transactions had modified this table and those missing files. What is surprising to me is that even if the files were missing the recover phase ended successfully. I expect an error (for example file not found) raised when postgresql try to apply the wal entries related to this table and those files. After the recover I find that these three file has been created during recover but when I try to query the table I get the error: > > db4=# select count(*) from pgbench_accounts ; > > ERROR: could not read block 1999996 in file "pg_tblspc/16471/PG_9.4_201409291/16474/16593.15": read only 0 of 8192 bytes Can you please get a backtrace from this error? I suspect that the problem here is that the planner is trying to estimate cardinality by descending a btree index, and failing because the index points to a part of the table that has been truncated. But if the table has been truncated because it's unlogged, then the index should have been truncated too; and if it's a permanent table, then it has been truncated improperly (because no index pointer to the truncated part should remain). What files do exist for pg_tblspc/16471/PG_9.4_201409291/16474/16593* ? (In particular I'm curious about whether 16593.14 exists and what size it is) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services