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 1gNNxl-0005Lp-1R for pgsql-admin@arkaria.postgresql.org; Thu, 15 Nov 2018 20:10:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gNNxj-0001gY-Ap for pgsql-admin@arkaria.postgresql.org; Thu, 15 Nov 2018 20:10:03 +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 1gNNxj-0001gR-0t for pgsql-admin@lists.postgresql.org; Thu, 15 Nov 2018 20:10:03 +0000 Received: from mail-oi1-x22a.google.com ([2607:f8b0:4864:20::22a]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gNNxg-0002zz-A6 for pgsql-admin@postgresql.org; Thu, 15 Nov 2018 20:10:02 +0000 Received: by mail-oi1-x22a.google.com with SMTP id v6so5517177oif.2 for ; Thu, 15 Nov 2018 12:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=6AC8X471WN+pBTtQGVXSg0I/MLfo3r/IwTnFZtN6c24=; b=DaqfnOojgz7DzS9vNx3o7xxAVaMwWAKCd+deSXuGAiF2oFUyZeDItYXYzxshmaKsi4 GDkc6rR+VWJumylSBdVMxv2BT7USBSPimjt1CXZi9qoBozcYL4Ij5qQKhdTJlinDrHHy obaJBM7dx5/LqEw1+kY1N7HYJWgLfL7WneDQZFjIIaOO292h4FdN40a0N5dd20zFqXep lvulSh/SUsqklJl2LnovUJKcqpA2gMpSRbU4foCZuYxtm84xXyYQyCZqGWVYXJedYsGj m9fSx9i6ShOYcfR1L/3SKqTCWgWstVaAWvGvDD4KvovryhzNy+jzGl/d7gAdxLop8NlX Yrlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6AC8X471WN+pBTtQGVXSg0I/MLfo3r/IwTnFZtN6c24=; b=THdFzI5qRQGGdkp4ipWOoJ2RnzYcGjyNBQBnYUWJfOgozTXvQ0267PkMQs0tE35qQR U4QG3eQAxazpAKYbxJj/XvtDZjiWipii8iKSlzFUi38fNkfGIZnMMpJHVxckdWqrJvK8 5BJcdW3NKAQ86e6IW2ORK7JNDkqpIfu5tC5PPQGAoBs2uZa4CtgoxI9fM6wWjv2QNajQ UN/WSje+P7H3kSUVid/MJCj6ubHKPgB0ulYW1PHVgOVDHDkQ381UY9DZw/l/V/O4Hq4g ArWGL9S27vy7DjUlNYJ8blIgUnM4lpjM784PUtGNz4vYkcNthC+owp/1VsWTfljgNoM7 ZFfQ== X-Gm-Message-State: AGRZ1gIUtEna32WAV2EqCLsIhJL8DaYMJnQ7NShfwhh5BeS7mtQC1Nvs yH98EmWP09Jpx0i5aVYN7mkUqFpm X-Google-Smtp-Source: AJdET5dBkV3Gb4XQg77/vFwkvVbM0MsnqWurBGiz750Qhi9U2fUjeXbDQY4Cx7NI+sGHETWY3ZjUNw== X-Received: by 2002:aca:2409:: with SMTP id n9mr3343535oic.40.1542312597643; Thu, 15 Nov 2018 12:09:57 -0800 (PST) Received: from [192.168.1.10] (ip70-171-116-89.no.no.cox.net. [70.171.116.89]) by smtp.googlemail.com with ESMTPSA id o15sm8079951otb.3.2018.11.15.12.09.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 12:09:56 -0800 (PST) Subject: Re: Can't find a relation in pg_class To: Pgsql-admin References: <20181115200208.lo3idqo3vvbb4vut@alvherre.pgsql> From: Ron Message-ID: Date: Thu, 15 Nov 2018 14:09:55 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181115200208.lo3idqo3vvbb4vut@alvherre.pgsql> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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. -- Angular momentum makes the world go 'round.