summaryrefslogtreecommitdiffstats
path: root/doc/src/sgml/html/logical-replication-publication.html
blob: a99e75aebcf1a3e641d998a360550acfa9dea6ce (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>31.1. Publication</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="logical-replication.html" title="Chapter 31. Logical Replication" /><link rel="next" href="logical-replication-subscription.html" title="31.2. Subscription" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">31.1. Publication</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="logical-replication.html" title="Chapter 31. Logical Replication">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="logical-replication.html" title="Chapter 31. Logical Replication">Up</a></td><th width="60%" align="center">Chapter 31. Logical Replication</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="logical-replication-subscription.html" title="31.2. Subscription">Next</a></td></tr></table><hr /></div><div class="sect1" id="LOGICAL-REPLICATION-PUBLICATION"><div class="titlepage"><div><div><h2 class="title" style="clear: both">31.1. Publication <a href="#LOGICAL-REPLICATION-PUBLICATION" class="id_link">#</a></h2></div></div></div><p>
   A <em class="firstterm">publication</em> can be defined on any physical
   replication primary.  The node where a publication is defined is referred to
   as <em class="firstterm">publisher</em>.  A publication is a set of changes
   generated from a table or a group of tables, and might also be described as
   a change set or replication set.  Each publication exists in only one database.
  </p><p>
   Publications are different from schemas and do not affect how the table is
   accessed.  Each table can be added to multiple publications if needed.
   Publications may currently only contain tables and all tables in schema.
   Objects must be added explicitly, except when a publication is created for
   <code class="literal">ALL TABLES</code>.
  </p><p>
   Publications can choose to limit the changes they produce to
   any combination of <code class="command">INSERT</code>, <code class="command">UPDATE</code>,
   <code class="command">DELETE</code>, and <code class="command">TRUNCATE</code>, similar to how triggers are fired by
   particular event types. By default, all operation types are replicated.
   These publication specifications apply only for DML operations; they do not affect the initial
   data synchronization copy. (Row filters have no effect for
   <code class="command">TRUNCATE</code>. See <a class="xref" href="logical-replication-row-filter.html" title="31.3. Row Filters">Section 31.3</a>).
  </p><p>
   A published table must have a <em class="firstterm">replica identity</em> configured in
   order to be able to replicate <code class="command">UPDATE</code>
   and <code class="command">DELETE</code> operations, so that appropriate rows to
   update or delete can be identified on the subscriber side.  By default,
   this is the primary key, if there is one.  Another unique index (with
   certain additional requirements) can also be set to be the replica
   identity.  If the table does not have any suitable key, then it can be set
   to replica identity <code class="literal">FULL</code>, which means the entire row becomes
   the key.  When replica identity <code class="literal">FULL</code> is specified,
   indexes can be used on the subscriber side for searching the rows.  Candidate
   indexes must be btree, non-partial, and the leftmost index field must be a
   column (not an expression) that references the published table column.  These
   restrictions on the non-unique index properties adhere to some of the
   restrictions that are enforced for primary keys.  If there are no such
   suitable indexes, the search on the subscriber side can be very inefficient,
   therefore replica identity <code class="literal">FULL</code> should only be used as a
   fallback if no other solution is possible.  If a replica identity other
   than <code class="literal">FULL</code> is set on the publisher side, a replica identity
   comprising the same or fewer columns must also be set on the subscriber
   side.  See <a class="xref" href="sql-altertable.html#SQL-ALTERTABLE-REPLICA-IDENTITY"><code class="literal">REPLICA IDENTITY</code></a> for details on
   how to set the replica identity.  If a table without a replica identity is
   added to a publication that replicates <code class="command">UPDATE</code>
   or <code class="command">DELETE</code> operations then
   subsequent <code class="command">UPDATE</code> or <code class="command">DELETE</code>
   operations will cause an error on the publisher.  <code class="command">INSERT</code>
   operations can proceed regardless of any replica identity.
  </p><p>
   Every publication can have multiple subscribers.
  </p><p>
   A publication is created using the <a class="link" href="sql-createpublication.html" title="CREATE PUBLICATION"><code class="command">CREATE PUBLICATION</code></a>
   command and may later be altered or dropped using corresponding commands.
  </p><p>
   The individual tables can be added and removed dynamically using
   <a class="link" href="sql-alterpublication.html" title="ALTER PUBLICATION"><code class="command">ALTER PUBLICATION</code></a>.  Both the <code class="literal">ADD
   TABLE</code> and <code class="literal">DROP TABLE</code> operations are
   transactional; so the table will start or stop replicating at the correct
   snapshot once the transaction has committed.
  </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="logical-replication.html" title="Chapter 31. Logical Replication">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="logical-replication.html" title="Chapter 31. Logical Replication">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="logical-replication-subscription.html" title="31.2. Subscription">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 31. Logical Replication </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 31.2. Subscription</td></tr></table></div></body></html>