Re: Logical Replication WIP

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