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)
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
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)
I am also having issues adding a table to a publication ,it doesn't seem
work
P: create publication tpub for table a;
S: create subscription mysub connection 'host=localhost dbname=test
port=5440' publication tpub;
P: insert into a(b) values ('1');
P: alter publication tpub add table b;
P: insert into b(b) values ('1');
P: insert into a(b) values ('2');
select * FROM pg_publication_tables ;
pubname | schemaname | tablename
---------+------------+-----------
tpub | public | a
tpub | public | b
but
S: select * FROM b;
a | b
---+---
(0 rows)
S: select * FROM a;
a | b
---+---
5 | 1
6 | 2
(2 rows)
diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
new file mode 100644
index 63af1a5..89723c3
*** a/doc/src/sgml/logical-replication.sgml
--- b/doc/src/sgml/logical-replication.sgml
***************
*** 95,110 ****
how the table is accessed. Each table can be added to multiple
publications if needed. Publications may currently only contain
tables. Objects must be added explicitly, except when a publication
! is created for <literal>ALL TABLES</>. There is no default name for
! a publication which specifies all tables.
</para>
<para>
Publications can choose to limit the changes they produce to show
any combination of <command>INSERT</>, <command>UPDATE</> and
<command>DELETE</> in a similar way to the way triggers are fired by
! particular event types. Only tables with a <literal>REPLICA IDENTITY</>
! index can be added to a publication which replicates <command>UPDATE</>
! and <command>DELETE</> operation.
</para>
<para>
The definition of a publication object will be included within
--- 95,110 ----
how the table is accessed. Each table can be added to multiple
publications if needed. Publications may currently only contain
tables. Objects must be added explicitly, except when a publication
! is created for <literal>ALL TABLES</>.
</para>
<para>
Publications can choose to limit the changes they produce to show
any combination of <command>INSERT</>, <command>UPDATE</> and
<command>DELETE</> in a similar way to the way triggers are fired by
! particular event types. If a table with without a <literal>REPLICA IDENTITY</>
! index is added to a publication which replicates <command>UPDATE</> or
! <command>DELETE</> operations then subsequent <command>UPDATE</>
! or <command>DELETE</> operations will fail on the publisher.
</para>
<para>
The definition of a publication object will be included within
***************
*** 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">
<title>Architecture</title>
--- 195,206 ----
</para>
<para>
A conflict will produce an error and will stop the replication; it
! must be resolved manually by the user. Details about the conflict can
! be found in the subscribers PostgreSQL log.
</para>
<para>
! The resolution can only be accomplished by manualy changing the
! subscriber so that it does not conflict with incoming change.
</sect1>
<sect1 id="logical-replication-architecture">
<title>Architecture</title>
***************
*** 229,237 ****
loads the standard logical decoding plugin (pgoutput). The plugin
transforms the changes read from WAL to the logical replication protocol
(see <xref linkend="protocol-logical-replication">) and filters the data
! according to publication specification. The data are then continuously
transferred using the streaming replication protocol to the Apply worker
! which maps them to the local tables and applies the individual changes as
they are received in exact transactional order.
</para>
<para>
--- 221,229 ----
loads the standard logical decoding plugin (pgoutput). The plugin
transforms the changes read from WAL to the logical replication protocol
(see <xref linkend="protocol-logical-replication">) and filters the data
! according to publication specification. The data is then continuously
transferred using the streaming replication protocol to the Apply worker
! which maps the data to local tables and applies the individual changes as
they are received in exact transactional order.
</para>
<para>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
