Subject: Re: Can't find a relation in pg_class
To: Pgsql-admin <pgsql-admin@postgresql.org>
References: <b7852f9d-e530-2ae6-f77b-2c17f3eed414@gmail.com>
 <17469.1542308167@sss.pgh.pa.us>
From: Ron <ronljohnsonjr@gmail.com>
Message-ID: <244637b0-a121-d1f0-74b1-24c0facca308@gmail.com>
Date: Thu, 15 Nov 2018 13:57:38 -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: <17469.1542308167@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk

On 11/15/2018 12:56 PM, Tom Lane wrote:
> Ron <ronljohnsonjr@gmail.com> 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?

> Another possibility is that you can't see the row because it's either
> uncommitted (new table) or committed dead (just-deleted table).  But
> it's not real clear how there could be a lock conflict in such cases.

That's what puzzles us.  (It's part of a huge transaction which drops old 
bits of partitoned tables and then adds new bits.  It worked flawlessly in 
8.4 but not in 9.6.)


-- 
Angular momentum makes the world go 'round.