On Sat, Feb 19, 2022 at 1:17 AM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada <sawada.mshk@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
couldjust be a view. A permanent record probably would best be recorded in the logs - though if we get the pre-skip
functionalitythe user can view directly and save the results wherever they wish or we can provide a function to spool
theinformation 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
commandto auto-disable the subscription after the transaction has been skipped and before any subsequent transactions
areapplied. This will give the user a chance to process the post-skipped information before restoring sync and having
thesystem begin changing underneath them again.
>
I think it can be helpful and probably can be done as a separate patch?
--
With Regards,
Amit Kapila.