On 02.02.22 07:54, Amit Kapila wrote:
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).
We could name the table something like pg_subscription_worker_error, so
it's explicit that it is collecting error information only.
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?
Let's flip this around and ask, why not? Tables are the place to store
data, by default.
