On Sat, Feb 19, 2022 at 1:17 AM David G. Johnston <david.g.johns...@gmail.com> wrote: > > On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: >> >> 5. Record skipped data to the system catalog, say >> pg_subscription_conflict_history so that there is a chance to analyze >> and recover. > > >> We can discuss the >> details in a new thread. > > Agreed - the "before skipping" consideration seems considerably more helpful; > but wouldn't need to be persistent, it could just be a view. A permanent > record probably would best be recorded in the logs - though if we get the > pre-skip functionality the user can view directly and save the results > wherever they wish or we can provide a function to spool the information to > the log. I don't see persistent in-database storage being that desirable > here. >
We can consider this but note that it could fill up a lot of LOG and difficult to find/interpret information. Say after skipping and logging half of the transaction data, there is some error like "connection error", it will then repeat the entire table data again. Also, say the table has toast columns, we have some mechanism to write such data in tables (like by compressing, etc) but printing huge data in Logs would be tricky and it may not be easier to read it, we may even need some sort of tuple header, column header etc. Also, there could be errors from other sessions in-between which we should be able to filter out but still it's may not be that clear. > If we only do something after the transaction has been skipped it may be > useful to add an option to the skipping command to auto-disable the > subscription after the transaction has been skipped and before any subsequent > transactions are applied. This will give the user a chance to process the > post-skipped information before restoring sync and having the system begin > changing underneath them again. > I think it can be helpful and probably can be done as a separate patch? -- With Regards, Amit Kapila.
