On Wed, Feb 2, 2022 at 9:41 AM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Tue, Feb 1, 2022 at 8:07 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> On Tue, Feb 1, 2022 at 11:47 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>
>> >
>> > I see that it's better to use a better IPC for ALTER SUBSCRIPTION SKIP
>> > feature to pass error-XID or error-LSN information to the worker
>> > whereas I'm also not sure of the advantages in storing all error
>> > information in a system catalog. Since what we need to do for this
>> > purpose is only error-XID/LSN, we can store only error-XID/LSN in the
>> > catalog? That is, the worker stores error-XID/LSN in the catalog on an
>> > error, and ALTER SUBSCRIPTION SKIP command enables the worker to skip
>> > the transaction in question. The worker clears the error-XID/LSN after
>> > successfully applying or skipping the first non-empty transaction.
>> >
>>
>> Where do you propose to store this information?
>
>
> pg_subscription_worker
>
> The error message and context is very important. Just make sure it is only non-null when the worker state is
"syncingfailed" (or whatever term we use).
>
>
Sure, but is this the reason you want to store all the error info in
the system catalog? I agree that providing more error info could be
useful and also possibly the previously failed (apply) xacts info as
well but I am not able to see why you want to have that sort of info
in the catalog. I could see storing info like err_lsn/err_xid that can
allow to proceed to apply worker automatically or to slow down the
launch of errored apply worker but not all sort of other error info
(like err_cnt, err_code, err_message, err_time, etc.). I want to know
why you are insisting to make all the error info persistent via the
system catalog?
--
With Regards,
Amit Kapila.