Finalizing logical replication limitations as well as potentialfeatures
От | Joshua D. Drake |
---|---|
Тема | Finalizing logical replication limitations as well as potentialfeatures |
Дата | |
Msg-id | c0bd70aa-7254-6217-1442-ec7bf144929c@commandprompt.com обсуждение исходный текст |
Ответы |
Re: Finalizing logical replication limitations as well as potential features
|
Список | pgsql-hackers |
-Hackers, As I continue to test Logical Replication and its native capabilities I have found the following: It appears it is not possible to do this: publisher->public.foo replicates to subscriber->private.foo This one seems like a relatively simple fix (theoretically) and I think should be done. I can imagine dozens of scenarios where I want a source to replicate to a destination but within a different schema. It also appears I can't do this: publisher->public.foo replicates to subscriber->partitioned->public.foo Here I was hoping that we could have multiple sources replicating into single partitioned table that would automatically segregate the database based on the partition key. Lastly, I noted that a full sync of a replication set is performed by a COPY, this is fine for small sets but if we have a large data set that may take some time it may be a problem with overall performance and maintenance. We may want to see if we can do an initial sync incrementally (optional) via a cursor (?) and queue all changed rows until the sync completes? Just some thoughts, I tried to ask on Slack as well as IRC but it doesn't appear many of the community are doing much with Logical Rep yet. Thanks in advance, JD -- Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc PostgreSQL centered full stack support, consulting and development. Advocate: @amplifypostgres || Learn: https://postgresconf.org ***** Unless otherwise stated, opinions are my own. *****
В списке pgsql-hackers по дате отправления: