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  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: parallel vacuum comments
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: parallel vacuum comments