Re: Proposal: Conflict log history table for Logical Replication
| От | Amit Kapila |
|---|---|
| Тема | Re: Proposal: Conflict log history table for Logical Replication |
| Дата | |
| Msg-id | CAA4eK1KYo0vZpPSRc_4gVpa06-J39gxjs3tHFyckgkBfYJSfFA@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 Thu, Dec 11, 2025 at 5:10 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Thu, Dec 11, 2025 at 5:04 PM shveta malik <shveta.malik@gmail.com> wrote: > > > 2) > > When we do below: > > alter subscription sub1 SET (conflict_log_table=clt2); > > > > the previous conflict log table is dropped. Is this behavior > > intentional and discussed/concluded earlier? It’s possible that a user > > may want to create a new conflict log table for future events while > > still retaining the old one for analysis. If the subscription itself > > is dropped, then dropping the CLT makes sense, but I’m not sure this > > behavior is intended for ALTER SUBSCRIPTION. I do understand that > > once we unlink CLT from subscription, later even DROP subscription > > cannot drop it, but user can always drop it when not needed. > > > > If we plan to keep existing behavior, it should be clearly documented > > in a CAUTION section, and the command should explicitly log the table > > drop. > > Yeah we discussed this behavior and the conclusion was we would > document this behavior and its user's responsibility to take necessary > backup of the conflict log table data if they are setting a new log > table or NONE for the subscription. > +1. If we don't do this then it will be difficult to track for postgres or users the previous conflict history tables. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: