Re: [Postgres-xc-bugs] Corrupt Objects

[West, W. <ww...@uc...>]

Sorry forget the version in my last response:

psql (PGXC 1.1, based on PG 9.2.4)


Regards,

bw

On 11/13/13, 3:39 PM, "West, William" <ww...@uc...> wrote:

>I am deploying a database to a production server that was developed
>without a problem on my dev platform. There are a couple of schemas and 4
>tables. I can create and populate the tables but once I apply a primary
>key to one of the tables, it is no longer available for any DML operation.
>Apparently it cannot find the primary key wherever it is looking for it.
>If I recreate the table under a new name and populate and apply the
>primary key it works fine but now I am stuck with two useless objects
>which will interfere with maintenance routines down the line.
>
>My production environment is fairly unique in that I am deploying this
>instance on a new supercomputer architecture and this could very possible
>be the source of this instability (since this all works on my dev cluster
>which is just a couple of linux VM nodes). However, I don¹t know where to
>look at the metadata or logs to find out what is wrong.
>
>I have reinitialized and rebuilt the database a number of time but this
>won¹t be a real option when the project goes live (I hope) since it takes
>quite a bit of time even when doing a restore. Is there any manual way to
>remove these objects (limited to the table and primary key)from metadata
>tables and therefore eliminate them from the instance?
>
>Thanks,
>
>bw
>
>On 11/13/13, 3:27 PM, "Michael Paquier" <mic...@gm...> wrote:
>
>>On Thu, Nov 14, 2013 at 5:34 AM, West, William <ww...@uc...> wrote:
>>> drop table gene.mutect cascade;
>>> ERROR: cache lookup failed for relation 24594
>>> It doesn¹t seemed based on what I read that there is a mechanism to
>>>drop
>>> corrupted objects. I hope this isn¹t the case since being unable to
>>>remove
>>> invalid objects would make this product unsuitable for production work.
>>This is clearly a bug. This error appears because even if this session
>>has taken a lock on this relation that should guarantee its presence,
>>well it is not here, hence the error.
>>
>>Telling first what is the version used, and then giving an explicit
>>test case would help the dev team to solve this issue.
>>Regards,
>>-- 
>>Michael
>