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 1gNOFK-0006CZ-JK for pgsql-admin@arkaria.postgresql.org; Thu, 15 Nov 2018 20:28:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gNOFI-000388-RT for pgsql-admin@arkaria.postgresql.org; Thu, 15 Nov 2018 20:28:12 +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 1gNOFI-000380-Dy for pgsql-admin@lists.postgresql.org; Thu, 15 Nov 2018 20:28:12 +0000 Received: from mail-qk1-x742.google.com ([2607:f8b0:4864:20::742]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gNOFF-0003Q9-Ah for pgsql-admin@postgresql.org; Thu, 15 Nov 2018 20:28:11 +0000 Received: by mail-qk1-x742.google.com with SMTP id 131so33910490qkd.4 for ; Thu, 15 Nov 2018 12:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=gR+VpzzzIGL54zVdLvhbM4yZMCU3c03LFg4svYH5VXE=; b=ey0WVYpBeRsVkrUNDCl5ENnSb8hDjyMQMq17miBIdqkS4GbrpIchgdHUXFmdwO0bvH Zpb5vg/LA3mk7q24gXF/BtVj0NI2yt+AeCopGPgo69khWRXOnRyUkw6rnCS8s1SJweKR qzHoOQYKTnvc+to/8iDvOL2gDgGJxo/z8S5UZBqRI/ZouVMZ5AQj0G9tvVNiX4J2hh7G 4IU/uZJdZW/PJ4FmvQJ0PZ9/aHRsHgYCnb/Uwfd8LEDOY2QxkLP17rtlD6Phc1XkmyNA JxdtNqoNLTnWHSAfRaCd8UCzqSOJcXrm9At6i+l1iHeu/JLWYMP/eIxIOXNsxZQI+LGC pvAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=gR+VpzzzIGL54zVdLvhbM4yZMCU3c03LFg4svYH5VXE=; b=SBfLg+8JZ+8rC0SHyx6Zkt7Z1PtQqZaBbtBmgaqG6rtdm7GI1j9rrQEpFBVJX2PGdN ws7D2j8oYK172VFNRypCEMOel1hUpAn5sg3qkjBOiYgjrabRDO8Y7eGRpbNOl/MkKGQl PqF9vl3GYpm1RDWuTV0GcFgVRujnHAHyRdR/Z5dgX2cuYlGTEEaE4dDKQrpskj1MWz3k BOS07vX5r2/tVizQQFjCjVRE4Yd5/S1Omib9ajeOQbKEQtnp+PtHk6o5qKgut0ft9DDD rzomHggk/+3682j2wWGn7fZ98Wo31R3a6QqsOm+TBq9PzP+VeCs82l3eUEcoR/wBz+pt v/eA== X-Gm-Message-State: AGRZ1gJOY15GYcPc0WF+xDnM3GSpkhHGiP+2OFfqw4XwgXd6R0SHIgUJ hTxTbNPiThcq3qyd7qVA9a/qrw== X-Google-Smtp-Source: AJdET5dVt8PRjnBfJiCN/+mWCJfD11zC0kkuLWTLJRK18WMfwtU1KarS8tbh1Tqqzww1mKynIOqiuw== X-Received: by 2002:a37:9841:: with SMTP id a62mr7447702qke.348.1542313687494; Thu, 15 Nov 2018 12:28:07 -0800 (PST) Received: from alvin.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id 49sm10135120qtz.55.2018.11.15.12.28.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 15 Nov 2018 12:28:06 -0800 (PST) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id A1A7612D; Thu, 15 Nov 2018 17:28:04 -0300 (-03) Date: Thu, 15 Nov 2018 17:28:04 -0300 From: Alvaro Herrera To: Ron Cc: Pgsql-admin Subject: Re: Can't find a relation in pg_class Message-ID: <20181115202804.kup5jpbkx6tf7zxe@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2018-Nov-15, Ron wrote: > On 11/15/2018 02:02 PM, Alvaro Herrera wrote: > > On 2018-Nov-15, Ron wrote: > > > > > On 11/15/2018 12:56 PM, Tom Lane wrote: > > > > Ron writes: > > > > > 10.143.169.100(38184) TAP TAPb 14310 PARSE waiting [unknown] 00000 > > > > >        LOG:  process 14310 still waiting for AccessShareLock > > > > >        on relation *767445914* of database *767442254* after 1000.389 ms at > > > > > character 39 > > > > > We found this in the log file, so went looking for what relation 767445914 > > > > > is, but don't see it in the pg_class table.  Am I doing something wrong? > > > > This message would be citing relation OID not relfilenode, I believe. > > > In what table? > > select ... from pg_class where oid = 767445914 > > That's what I thought.  But select oid, relfilenode from pg_class shows that > c.oid always has the same value as c.relfilenode. Then the other cases Tom mentioned apply. (Note that that equality doesn't apply in general. The relfilenode will change on VACUUM FULL, or CLUSTER, or table-rewriting ALTER TABLE, whereas the OID will always stay unchanged.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services