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