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?

If you take your schema + slony setup and try this on a database with no 
data do the set subscriptions complete?

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)



> 
> the tables with this problem, AFAICS, are those that are inherited (a
> partition scheme, but not all inherited tables). ideas?
> 
> -[ RECORD 1 ]----+------------------------------
> relid            | 22868
> schemaname       | public
> relname          | tcom_invitacion_200902
> seq_scan         | 28
> seq_tup_read     | 14791170
> idx_scan         | 0
> idx_tup_fetch    | 0
> n_tup_ins        | 2465195
> n_tup_upd        | 0
> n_tup_del        | 0
> n_tup_hot_upd    | 0
> n_live_tup       | 0
> n_dead_tup       | 0
> last_vacuum      | 2010-03-20 22:59:38.858321-05
> last_autovacuum  |
> last_analyze     | 2010-03-20 22:59:38.858321-05
> last_autoanalyze | 2010-03-20 13:24:02.694223-05
> 


-- 
Steve Singer
Afilias Canada
Data Services Developer
416-673-1142