On 3/11/20 1:22 AM, PegoraroF10 wrote:
Well, for now it´s solved but I´ll explain what happens to solve it better on
future.
Suppose on Master you have a database with hundreds of schemas with same
structure, so table Customer happens 500 times on that DB. That database
being replicated with publ
Well, for now it´s solved but I´ll explain what happens to solve it better on
future.
Suppose on Master you have a database with hundreds of schemas with same
structure, so table Customer happens 500 times on that DB. That database
being replicated with publication/subscription for all tables model
On 3/10/20 8:42 AM, PegoraroF10 wrote:
built in logical replication
Well it does not do DDL replication so I am not sure how the new table
is getting to the replica?
It might help if you provide an start to end example of what you are doing.
--
Sent from: https://www.postgresql-archive.
built in logical replication
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
On 3/10/20 5:16 AM, PegoraroF10 wrote:
Now I have the same problem with a different message.
I´ve added a table on all schemas and did a refresh publication. when
postgres sees a new table on publisher he goes to replicamand trucates that
table to start copying. ok but I have 300 schemas, how can
Now I have the same problem with a different message.
I´ve added a table on all schemas and did a refresh publication. when
postgres sees a new table on publisher he goes to replicamand trucates that
table to start copying. ok but I have 300 schemas, how can I know what
schema that table belongs to
correct, what schema that table belongs to.
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
On 3/8/20 12:26 PM, PegoraroF10 wrote:
I have a publication/subscription replication.
Then this week started to see this message on Log of replica server.
Message is "duplicate key value violates unique constraint "pksyslookup""
Detail is "Key (lookup_id)=(56) already exists."
and on production
