Re: Questions about Logical Replication - Issue ??? - Mailing list pgsql-general

From Kyotaro Horiguchi
Subject Re: Questions about Logical Replication - Issue ???
Date
Msg-id 20200731.101329.1431222995489786995.horikyota.ntt@gmail.com
Whole thread Raw
In response to Questions about Logical Replication - Issue ???  (FOUTE K. Jaurès <jauresfoute@gmail.com>)
Responses Re: Questions about Logical Replication - Issue ???
List pgsql-general
Hi,

At Thu, 30 Jul 2020 14:54:08 +0100, FOUTE K. Jaurès <jauresfoute@gmail.com> wrote in
> Hi everyone,
>
> Situation:
>
>    - A Master Database on the HQ
>    - i make a dump of the master database to the Subdivision Server
>    - I create à Publication like: CREATE PUBLICATION
>    iNOV_MasterData_Table_Pub FOR TABLE M_Product; On the Master Database
>    - On the Subdivision Server, I create a Subscription like: CREATE
>    SUBSCRIPTION iNOV_MasterData_Table_XXX_Sub CONNECTION '........'
>    PUBLICATION  iNOV_MasterData_Table_Pub;
>    - On the log, I have this error:
>       - 2020-07-30 14:32:59.366 WAT [8022] ERROR:  duplicate key value
>       violates unique constraint "m_product_pkey"
>       2020-07-30 14:32:59.366 WAT [8022] DETAIL:  Key
>       (m_product_id)=(1001426) already exists.
>       2020-07-30 14:32:59.366 WAT [8022] CONTEXT:  COPY m_product, line 1
>       2020-07-30 14:32:59.369 WAT [1536] LOG:  background worker "logical
>       replication worker" (PID 8022) exited with exit code 1
>
> What can I do to solve this? Is it normal ? It
> BTW: When I create Subscription With the option  (copy_data = false), I am
> able to replicate the new record.

As you know, initial table copy happens defaultly at subscription
creation (the COPY command in the above log lines was doing that). If
you are sure that the publisher table is in-sync with the subscriber
one, you can use copy_data=false safely and it's the proper operation.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-general by date:

Previous
From: Jens.Wilke@parcIT.de
Date:
Subject: Costs of Heap Fetches in Postgres 13
Next
From: David Rowley
Date:
Subject: Re: Costs of Heap Fetches in Postgres 13