On Mon, Mar 22, 2010 at 10:18 PM, Steve Singer <ssinger at ca.afilias.info> 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