From: 鈴木 幸市 <ko...@in...> - 2013-10-09 06:33:18
|
Thanks Pavan for the comment. So possible approach to resolve this problem could be separate system column to maintain column identification, or asking primary key for replicated tables when trigger (and other CTID-dependent feature) is used. Any other ideas/thoughts? --- Koichi Suzuki On 2013/10/09, at 15:26, Pavan Deolasee <pav...@gm...<mailto:pav...@gm...>> wrote: On Wed, Oct 9, 2013 at 11:49 AM, Koichi Suzuki <koi...@gm...<mailto:koi...@gm...>> wrote: Hmm.. Yes, it could be serious. I suppose that CTID changes only when vacuum full occurs. CTID will also change every time a row is updated. So the bug should be very easy to reproduce. One easiest way to compile different datanodes with diferent block size. Another way could be to update/delete from a replicated table and vacuum the table on one datanode but not other and then again update several rows in the table. Most likely the new versions on two different nodes will not have the same CTID anymore. Vacuum freeze will updates xmim to the smallest value and usual vacuum recycles "dead" row area. We may have a chance to assign different CTIDs to the same rows in replicated table if vacuum full runs locally in datanodes. (My assumption may be wrong. Does vacuum freeze move tuples and change their CTID?) No, it does not. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk_______________________________________________ Postgres-xc-developers mailing list Pos...@li... https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers |