Re: Proposal: Conflict log history table for Logical Replication
От | Dilip Kumar |
---|---|
Тема | Re: Proposal: Conflict log history table for Logical Replication |
Дата | |
Msg-id | CAFiTN-uSs5kiJ6cMq9VZ03+wwOxGpsh707XX+1sWNO-9NcyXrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: Conflict log history table for Logical Replication (Dilip Kumar <dilipbalaut@gmail.com>) |
Список | pgsql-hackers |
On Sun, Sep 28, 2025 at 5:15 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Sun, Sep 28, 2025 at 2:43 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > I agree that option-2 is useful and IIUC, we are already working on > > something similar in thread [1]. However, it is better to use option-1 > > here because we are using non-user specified mechanism to skip changes > > during replication, so following the same during other times is > > preferable. Once we have that other feature [1], we can probably > > optimize this code to use it without taking input from the user. The > > other reason of not going with the option-2 in the way you are > > proposing is that it doesn't seem like a good idea to have multiple > > ways to specify skipping tables from publishing. I find the approach > > being discussed in thread [1] a generic and better than a new > > table-level option. > > > > [1] - https://www.postgresql.org/message-id/CANhcyEVt2CBnG7MOktaPPV4rYapHR-VHe5%3DqoziTZh1L9SVc6w%40mail.gmail.com > > I understand the current discussion revolves around using an EXCEPT > clause (for tables/schemas/columns) during publication creation. But > what we want is to mark some table which will be excluded permanently > from publication, because we can not expect users to explicitly > exclude them while creating publication. > > So, I propose we add a "non-publishable" property to tables > themselves. This is a more valuable option for users who are certain > that certain tables should never be replicated. > > By marking a table as non-publishable, we save users the effort of > repeatedly listing it in the EXCEPT option for every new publication. > Both methods have merit, but the proposed table property addresses the > need for a permanent, system-wide exclusion. > > See below test with a quick hack, what I am referring to. > > postgres[2730657]=# CREATE TABLE test(a int) WITH > (NON_PUBLISHABLE_TABLE = true); > CREATE TABLE > postgres[2730657]=# CREATE PUBLICATION pub FOR ALL TABLES ; > CREATE PUBLICATION > postgres[2730657]=# select pg_get_publication_tables('pub'); > pg_get_publication_tables > --------------------------- > (0 rows) > > > But I agree this is an additional table option which might need > consensus, so meanwhile we can proceed with option2, I will prepare > patches with option-2 and as a add on patch I will propose option-1. > And this option-1 patch can be discussed in a separate thread as well. So here is the patch set using option-2, with this when alltable option is used and we get pg_get_publication_tables(), this will check the relid against the conflict history tables in the subscribers and those tables will not be added to the list. I will start a separate thread for proposing the patch I sent in previous email. -- Regards, Dilip Kumar Google
Вложения
В списке pgsql-hackers по дате отправления: