Hi Anton, I seem to recall there was a bug with partitioned tables which may have resulted in the behavior you’re seeing. Can you try using the latest from HEAD and then letting us know if you’re still seeing that issue?
Thanks, David > On May 22, 2017, at 12:14 AM, Пацев Антон <[email protected]> wrote: > > Hello Friends! > I'm trying to use bucardo for logical replication with PostgreSQL 9.3 on 9.5. > > yum list bucardo > bucardo.noarch > 5.4.1-1.rhel6 > > > [local]:5432 postgres@database # \d+ table > > > Table "public.table > " > > Column | Type | Modifiers | Storage | Stats target > | Description > > > --------------+-----------------------------+-----------+----------+--------------+------------- > > > id | bigint | not null | plain | > | > > start_time > | timestamp without time zone | | plain | | > > end_time > | timestamp without time zone | | plain | | > > in_part > | integer | | plain | | > > in_offset > | bigint | | plain | | > > out_part > | integer | | plain | | > > out_offset > | bigint | | plain | | > > process_time > | bigint | | plain | | > > proc_status > | integer | | plain | | > > in_key > | character varying(128) | | extended | | > > out_key > | character varying(128) | | extended | | > > key_word > | json | | extended | | > > > description | text | | extended | > | > > job > | character varying(256) | | extended | | > > job_version > | character varying(128) | | extended | | > > in_topic > | character varying(256) | | extended | | > > out_topic > | character varying(256) | | extended | | > > Indexes: > "pk_table" > PRIMARY KEY, btree (id) > > "in_topic_metric_job_text_ > index" btree (in_topic) > > "table_expr_idx" > btree ((key_word ->> 'messageId'::text)) > > "table_job_text_index" > btree (job) > > "out_topic_metric_job_text_ > index" btree (out_topic) > > Triggers: > bucardo_delta > AFTER INSERT OR DELETE OR UPDATE ON table FOR EACH ROW EXECUTE PROCEDURE > bucardo.delta_public_table() > > bucardo_kick_database_sync > AFTER INSERT OR DELETE OR UPDATE OR TRUNCATE ON table FOR EACH STATEMENT > EXECUTE PROCEDURE bucardo.bucardo_kick_database_sync() > > bucardo_note_trunc_database_ > sync AFTER TRUNCATE ON table FOR EACH STATEMENT EXECUTE PROCEDURE > bucardo.bucardo_note_truncation('database_sync') > > trigger_create_table_ > partition_and_insert_function BEFORE INSERT ON table FOR EACH ROW EXECUTE > PROCEDURE create_table_partition_and_insert_function() > > Child tables: table_2017_05_10 > , > > table_2017_05_11 > , > > table_2017_05_12 > , > > table_2017_05_13 > , > > table_2017_05_14 > , > > table_2017_05_15 > , > > table_2017_05_16 > , > > table_2017_05_17 > , > > table_2017_05_18 > , > > table_2017_05_19 > Has OIDs: > no > > bucardo status > PID > of > Bucardo MCP: 4120 > > Name State Last good Time Last I/D Last > bad Time > > ========================== > +========+============+=========+===========+===========+ > ======= > table_sync > | Good | 15:31:36 | 17s | 0/0 | none | > > > > На 9.3 > SELECT count(*) from table; > > > count > > > -------- > > 499401 > > > > На 9.5 > SELECT count(*) from table; > count > > > -------- > > 641335 > > > Bucardo synchronizes and so it should be and this is the features of > PostgreSQL > Or is it Bucardo's mistake? > > -- > С уважением, Антон Пацев. > Best regards, Anton Patsev. > _______________________________________________ > Bucardo-general mailing list > [email protected] > https://mail.endcrypt.com/mailman/listinfo/bucardo-general -- David Christensen End Point Corporation [email protected] 785-727-1171 _______________________________________________ Bucardo-general mailing list [email protected] https://mail.endcrypt.com/mailman/listinfo/bucardo-general
