On Fri, Dec 12, 2025 at 10:02 AM shveta malik <[email protected]> wrote: > > On Fri, Dec 12, 2025 at 9:42 AM Dilip Kumar <[email protected]> wrote: > > > > On Fri, Dec 12, 2025 at 9:19 AM shveta malik <[email protected]> wrote: > > > > > > On Thu, Dec 11, 2025 at 7:49 PM Dilip Kumar <[email protected]> wrote: > > > > > > > > We do not need to make the CLT dependent on the subscription because > > > > the table can be dropped when the subscription is dropped anyway and > > > > we are already doing it as part of drop subscription as well as alter > > > > subscription when CLT is set to NONE or a different table. Therefore, > > > > extending the functionality of shared dependency is unnecessary for > > > > this purpose. > > > > > > > > Thoughts? > > > > > > I believe the recommendation to create a dependency was meant to > > > prevent the table from being accidentally dropped during a DROP SCHEMA > > > or DROP TABLE operation. That risk still remains, regardless of the > > > fact that dropping or altering a subscription will result in the table > > > removal. I will give this more thought and let you know if anything > > > comes to mind. > > > > I mean we can register the dependency of subscriber on table and that > > will prevent dropping the tables via DROP TABLE/DROP SCHEMA, but what > > I do not like is the internal error[1] in doDeletion() when someone > > will try to DROP TABLE CLT CASCADE; > > > > Yes, I understand that part. > > > I suggest an alternative approach for handling this: implement a check > > within the ALTER/DROP table commands. If the table is a CLT (using > > IsConflictLogTable() to verify), these operations should be > > disallowed. This would enhance the robustness of CLT handling by > > entirely preventing external drop/alter actions. What are your > > thoughts on this solution? And let's also see what Amit and Sawada-san > > think about this solution. > > I had similar thoughts, but was unsure how this should behave when a > user runs DROP SCHEMA … CASCADE. We can’t simply block the entire > operation with an error just because the schema contains a CLT, but we > also shouldn’t allow it to proceed without notifying the user that the > schema includes a CLT.
I understand your concern about whether this restriction is appropriate, particularly when using DROP SCHEMA … CASCADE is. However, considering the logical dependency where the subscription relies on the table (CLT), expecting DROP SCHEMA … CASCADE to drop the CLT implies it should also drop the dependent subscription, which is not permitted. Therefore, a more appropriate behavior would be to issue an error message stating that the table is a conflict log table and that subscriber "<subname>" depends on it. This message should instruct the user to either drop the subscription or reset the conflict log table before proceeding with the drop operation. OTOH, we can simply let the CLT get dropped and altered and document this behavior so that it is the user's responsibility to not to drop/alter the CLT otherwise conflict logging will be skipped as we have now. While thinking more I feel it might be better to keep it simple as we have now instead of overcomplicating it? -- Regards, Dilip Kumar Google
