On Mon, Mar 22, 2010 at 10:18 PM, Steve Singer <[email protected]> wrote: > Jaime Casanova wrote: >> >> On Tue, Oct 13, 2009 at 12:42 PM, Jaime Casanova > >> i have just seen this same problem in 1.2.20, looking a bit more seems >> like the table "was copied" (note the n_tup_ins in the >> pg_stat_user_tables record) still the table has no n_live_tup nor >> n_dead_tup so i guess it was truncated. why is slony truncating these >> tables a second time? > > > Is it possible that the initial copy failed part way through causing that > transaction to rollback? >
at first i didn't believe that, i thought that n_dead_tup should be charged in the case of a rollback... but that is not true... also i couldn't reproduce this in a test environment i even made a partitioned table like the original with the problem... > If you take your schema + slony setup and try this on a database with no > data do the set subscriptions complete? > the subcriptions complete, it just not copy all data... i dropped those table from the set and added them in another one and the copy was fine... then merge with the original set and no problem until now... > I'm trying to get a sense of if this is a problem that is being triggered by > some schemas with inheritance tables or if it is that some of your data is > causing things to fail (which still shouldn't happen) > yeah! i'm trying to figure out what caused the rollback if any -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
