On 13/11/16 23:02, Steve Singer wrote: > On 10/31/2016 06:38 AM, Petr Jelinek wrote: >> On 31/10/16 00:52, Steve Singer wrote: >> There are some fundamental issues with initial sync that need to be >> discussed on list but this one is not known. I'll try to convert this >> to test case (seems like useful one) and fix it, thanks for the >> report. In meantime I realized I broke the last patch in the series >> during rebase so attached is the fixed version. It also contains the >> type info in the protocol. >> > > Attached are some proposed documentation updates (to be applied ontop of > your 20161031 patch set) >
Merged into v8, thanks! There is one exception though: > *** 195,214 **** > </para> > <para> > A conflict will produce an error and will stop the replication; it > ! must be resolved manually by the user. > </para> > <para> > ! The resolution can be done either by changing data on the subscriber > ! so that it does not conflict with incoming change or by skipping the > ! transaction that conflicts with the existing data. The transaction > ! can be skipped by calling the > ! <link linkend="pg-replication-origin-advance"> > ! <function>pg_replication_origin_advance()</function></link> function > ! with a <literal>node_name</> corresponding to the subscription name. The > ! current position of origins can be seen in the > ! <link linkend="view-pg-replication-origin-status"> > ! <structname>pg_replication_origin_status</structname></link> system > view. > ! </para> > </sect1> > <sect1 id="logical-replication-architecture"> I don't see why this needs to be removed? Maybe it could be improved but certainly not removed? > Also > > <sect1 id="logical-replication-publication"> > <title>Publication</title> > > > + <para> > + The tables are matched using fully qualified table name. Renaming of > + tables or schemas is not supported. > + </para> > > Is renaming of tables any less supported than other DDL operations > For example > I changed that text as it means something completely different. > alter table nokey2 rename to nokey3 > select * FROM pg_publication_tables ; > pubname | schemaname | tablename > ---------+------------+----------- > tpub | public | nokey3 > (1 row) > > > If I then kill the postmaster on my subscriber and restart it, I get > > 2016-11-13 16:17:11.341 EST [29488] FATAL: the logical replication > target public.nokey3 not found > 2016-11-13 16:17:11.342 EST [29272] LOG: worker process: logical > replication worker 41076 (PID 29488) exited with exit code 1 > 2016-11-13 16:17:16.350 EST [29496] LOG: logical replication apply for > subscription nokeysub started > 2016-11-13 16:17:16.358 EST [29498] LOG: logical replication sync for > subscription nokeysub, table nokey2 started > 2016-11-13 16:17:16.515 EST [29498] ERROR: table public.nokey2 not > found on publisher > 2016-11-13 16:17:16.517 EST [29272] LOG: worker process: logical > replication worker 41076 sync 24688 (PID 29498) exited with exit code 1 > > but if I then rename the table on the subscriber everything seems to work. > > (I suspect the need to kill+restart is a bug, I've seen other instances > where a hard restart of the subscriber following changes to is required) > This is another initial sync patch bug. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers