Re: pg_get_publication_tables() output duplicate relid
От | Amit Langote |
---|---|
Тема | Re: pg_get_publication_tables() output duplicate relid |
Дата | |
Msg-id | CA+HiwqHX8LzgDfWM4-ZKzNFgQxMqnfUBRa4YghQkJDtoW6Ou7Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_get_publication_tables() output duplicate relid (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: pg_get_publication_tables() output duplicate relid
|
Список | pgsql-hackers |
On Tue, Nov 23, 2021 at 12:21 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > Isn't it better to document this case and explain what > users can expect instead of trying to design a solution around this? I thought about the problems you've described and it looks like I hadn't considered many of the details which complicate implementing a solution for this. So yeah, documenting the ATTACH issue as a limitation sounds like the best course for now. I might word it as follows and add it under Notes at https://www.postgresql.org/docs/current/sql-createpublication.html: "ATTACHing a table into a partition tree whose root is published using a publication with publish_via_partition_root set to true does not result in the table's existing contents to be replicated." I'm not sure there's a clean enough workaround to this that we can add to the paragraph. Does that make sense? > Even if we do so the streaming after attach partition problem as > discussed above should be fixed. I agree. I have reproduced the problem though haven't managed to pin down the cause yet. -- Amit Langote EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: