From: Koichi S. <koi...@gm...> - 2013-11-14 02:24:30
|
First of all, to analyze what is going on, it will be helpful if you set log_error_verbosity GUC in postgresql.conf to verbose. The message is printed in number of internal modules so this setting will help. You can do this from psql session but you may have to be a superuser. Second, do you have the same error when you restart the whole XC cluster? Regards; --- Koichi Suzuki 2013/11/14 West, William <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 > > > > > ------------------------------------------------------------------------------ > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk > _______________________________________________ > Postgres-xc-bugs mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs > |