Re: Proposal: Conflict log history table for Logical Replication
| От | Dilip Kumar |
|---|---|
| Тема | Re: Proposal: Conflict log history table for Logical Replication |
| Дата | |
| Msg-id | CAFiTN-vd8AccG5ON3Ug=7FMPOS_SHLCHV4ncGKSfsT=2C70WYQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal: Conflict log history table for Logical Replication (shveta malik <shveta.malik@gmail.com>) |
| Ответы |
Re: Proposal: Conflict log history table for Logical Replication
|
| Список | pgsql-hackers |
On Tue, Dec 16, 2025 at 10:33 AM shveta malik <shveta.malik@gmail.com> wrote: > The OID check may be unreliable, as mentioned in the comment. I tested > this by dropping and recreating information_schema, and observed that > after recreation it became eligible for publication because its relid > no longer falls under FirstNormalObjectId. Steps: > > ****Pub****: > create publication pub1; > ALTER PUBLICATION pub1 ADD TABLE information_schema.sql_sizing; > select * from information_schema.sql_sizing where sizing_id=97; > > ****Sub****: > create subscription sub1 connection '...' publication pub1 with > (copy_data=false); > select * from information_schema.sql_sizing where sizing_id=97; > > ****Pub****: > alter table information_schema.sql_sizing replica identity full; > --this is not replicated. > UPDATE information_schema.sql_sizing set supported_value=12 where sizing_id=97; > > ****Sub****: > postgres=# select supported_value from information_schema.sql_sizing > where sizing_id=97; > supported_value > ----------------- > 0 > > ~~ > > Then drop and recreate and try to perform the above update again, it > gets replicated: > > drop schema information_schema cascade; > ./psql -d postgres -f ./../../src/backend/catalog/information_schema.sql -p 5433 > > ****Pub****: > ALTER PUBLICATION pub1 ADD TABLE information_schema.sql_sizing; > select * from information_schema.sql_sizing where sizing_id=97; > alter table information_schema.sql_sizing replica identity full; > --This is replicated > UPDATE information_schema.sql_sizing set supported_value=14 where sizing_id=97; > > ****Sub****: > --This shows supported_value as 14 > postgres=# select supported_value from information_schema.sql_sizing > where sizing_id=97; > supported_value > ----------------- > 14 Hmm, I might be missing something what why we do not want to publish which is in information_shcema, especially when the internally created schema is dropped then user can create his own schema with name information-schema and create a bunch of tables in that so why do we want to block those? I mean the example you showed here is pretty much like a user created schema and table no? Or am I missing something important? -- Regards, Dilip Kumar Google
В списке pgsql-hackers по дате отправления: