On Wed, Feb 2, 2022 at 9:41 AM David G. Johnston <david.g.johns...@gmail.com> wrote: > > On Tue, Feb 1, 2022 at 8:07 PM Amit Kapila <amit.kapil...@gmail.com> wrote: >> >> On Tue, Feb 1, 2022 at 11:47 AM Masahiko Sawada <sawada.m...@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 "syncing failed" (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.
