|
From: Filip R. <fil...@gm...> - 2013-01-30 13:07:27
|
On Mon, Jan 28, 2013 at 7:23 PM, Koichi Suzuki <koi...@gm...>wrote: > I have not looked into it very in detail. So this is just a guess. > > XC's datanode cluster contains three more system catalogues, > pgxc_class, pgxc_node and pgxc_nodegroup and also contains many more > build-in functions which have to be hard-coded. > Only adding new objects is fine. I think it does not prevent this kind of migration. I can think of creating new objects in pg_catalog just before switching to Postgres-XC. Does postgres-xc modify any existing postgres catalog tables? (adding columns, changing types, any structure changes)? Does postgres-xc modify any existing postgres catalog functions? (function signatures and/or internal logic) Do you think it's possible to map/translate existing pg_class to pgxc_class, existing TXIDs to GXIDs, etc? I understand that pointing "empty" GTMs and Coordinators to this new special datanode would simply not work? We'd have to initialize them in a special way? > > Even though other part of the database cluster has no serious > difference, the above could be very serious. > answers to above questions would help me understand _why_ it is serious. > It looks a good idea to allow XC to start with only one node > configuration, and then add nodes as needed. > > Yes, that's my idea also - I see there are ALTER TABLE commands which allow to replicate/redistribute. > Other than that, you can use pg_dump and pg_restore to move all your > data from PostgreSQL to Postgres-XC. > > I know it's a standard procedure - but in my case this would take tens of hours, and I'm looking for other ways. Thank you, Filip |