Re: Proposal: Conflict log history table for Logical Replication
| От | Dilip Kumar |
|---|---|
| Тема | Re: Proposal: Conflict log history table for Logical Replication |
| Дата | |
| Msg-id | CAFiTN-tT=MrOz-wMyz-_QKPupFCZMv=yiaPFCs44OCTzMjVBMw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal: Conflict log history table for Logical Replication (Amit Kapila <amit.kapila16@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Dec 5, 2025 at 3:25 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Dec 4, 2025 at 4:20 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > Also, shall we give the option to the user where she wants to see > > conflict/resolution information? One idea to achieve the same is to > > provide subscription options like (a) conflict_resolution_format, the > > values could be log and table for now, in future, one could extend it > > to other options like xml, json, etc. (b) conflict_log_table: in this > > user can specify the conflict table name, this can be optional such > > that if user omits this and conflict_resolution_format is table, then > > we will use internally generated table name like > > pg_conflicts_<subscription_id>. > > > > In this idea, we can keep the name of the second option as > conflict_log_name instead of conflict_log_table. This can help us LOG > the conflicts in a totally separate conflict file instead of in server > log. Say, the user provides conflict_resolution_format as 'log' and > conflict_log_name as 'conflict_report' then we can report conflicts in > this separate file by appending subid to distinguish it. And, if the > user gives only the first option conflict_resolution_format as 'log' > then we can keep reporting the information in server log files. Yeah that looks good, so considering the extensibility I think we can keep the option name as 'conflict_log_name' from the first version itself even if we don't provide all the options in the first version. -- Regards, Dilip Kumar Google
В списке pgsql-hackers по дате отправления: