Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kAeGI-0001vy-3r for pgsql-admin@arkaria.postgresql.org; Tue, 25 Aug 2020 19:05:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kAeGG-0002CP-O5 for pgsql-admin@arkaria.postgresql.org; Tue, 25 Aug 2020 19:05:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kAeGG-0002CI-GB for pgsql-admin@lists.postgresql.org; Tue, 25 Aug 2020 19:05:36 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kAeGB-000709-QC for pgsql-admin@postgresql.org; Tue, 25 Aug 2020 19:05:35 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 07PJ5Rgt2760668; Tue, 25 Aug 2020 15:05:27 -0400 From: Tom Lane To: Wells Oliver cc: Stephen Frost , Alvaro Herrera , pgsql-admin Subject: Re: Odd pg dump error: cache lookup failure In-reply-to: References: <20200824231338.GA30623@alvherre.pgsql> <20200824231621.GA29590@tamriel.snowman.net> <2748788.1598376276@sss.pgh.pa.us> Comments: In-reply-to Wells Oliver message dated "Tue, 25 Aug 2020 11:23:25 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2760666.1598382327.1@sss.pgh.pa.us> Date: Tue, 25 Aug 2020 15:05:27 -0400 Message-ID: <2760667.1598382327@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Wells Oliver writes: > Interesting: the only parameters I pass are a list of excluded schemas via > -N arguments, as well as a --format=c. > I don't think anything in the excluded schemas is being referenced by > something that is set to be dumped: is that what you're thinking? It's > possible, and I'll dig a bit, but things are generally walled off pretty > well. I overlooked something in my previous quick code scan, which is that flagInhTables() will set the "interesting" flag on parents of tables that are due to be dumped, even if the parents are not. This *will* result in running getIndexes on tables that we have no lock on. However, it's not quite clear how that leads to the observed failure, because if we have a lock on some child partition, it shouldn't really be possible for someone to drop an index on the partition root, should it? In any case you didn't admit to doing such things. This theory would require both that a table-to-be-dumped is a partition of some partitioned table that's in an excluded schema, and that you're concurrently doing DDL on that partitioned table. regards, tom lane