Re: Proposal: Conflict log history table for Logical Replication
От | Amit Kapila |
---|---|
Тема | Re: Proposal: Conflict log history table for Logical Replication |
Дата | |
Msg-id | CAA4eK1+ESfoUMQkRmcUUyM6oDWVZnPHk9vOqC=V_vHO9X5Tf-g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: Conflict log history table for Logical Replication (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Proposal: Conflict log history table for Logical Replication
|
Список | pgsql-hackers |
On Fri, Sep 26, 2025 at 4:42 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Thu, Sep 25, 2025 at 4:19 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > On Thu, Sep 25, 2025 at 11:53 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > > [1] > > > > /* > > > > * For logical decode we need combo CIDs to properly decode the > > > > * catalog > > > > */ > > > > if (RelationIsAccessibleInLogicalDecoding(relation)) > > > > log_heap_new_cid(relation, &tp); > > > > > > > > > > Meanwhile I am also exploring the option where we can just CREATE TYPE > > > in initialize_data_directory() during initdb, basically we will create > > > this type in template1 so that it will be available in all the > > > databases, and that would simplify the table creation whether we > > > create internally or we allow user to create it. And while checking > > > is_publishable_class we can check the type and avoid publishing those > > > tables. > > > > > > > Based on my off list discussion with Amit, one option could be to set > > HEAP_INSERT_NO_LOGICAL option while inserting tuple into conflict > > history table, for that we can not use SPI interface to insert instead > > we will have to directly call the heap_insert() to add this option. > > Since we do not want to create any trigger etc on this table, direct > > insert should be fine, but if we plan to create this table as > > partitioned table in future then direct heap insert might not work. > > Upon further reflection, I realized that while this approach avoids > streaming inserts to the conflict log history table, it still requires > that table to exist on the subscriber node upon subscription creation, > which isn't ideal. > I am not able to understand what exact problem you are seeing here. I was thinking that during the CREATE SUBSCRIPTION command, a new table with user provided name will be created similar to how we create a slot. The difference would be that we create a slot on the remote/publisher node but this table will be created locally. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: